Let’s talk about synthetic tests? We noticed that some customers use them, assessing the “professional suitability” of any cloud solution. Sometimes we are asked to provide the results of a test or test the system ourselves during a free trial. Moreover, the same load testing is rarely performed. The favorites are the Gilev test. We will tell you about him. After all, if you do such a test, then you need to do it correctly.
It should be understood that Gilev’s test in no way reflects the performance of a real configuration with a real database. It runs on an empty platform without installing any configurations, let alone loading real 1C databases. But a multi-threaded test can be run as a load test and on a real system with real data.
Moreover, the test was primarily developed to test discrete servers (since they are recommended by the platform manufacturer), and the single-threaded test was originally developed to test the file storage architecture of 1C databases. And if there are recommendations for setting up discrete servers and operating systems on the authors’ website, although incomplete and partly outdated, then for virtual and cloud technologies there is only an invitation to conclude an agreement with the authors of the test for optimization work.
However, many technicians consider the test results to be the ultimate truth, placing great emphasis on the results. At the same time, they often pay attention only to the results of a single-threaded test, as the most visual and simple ones. This is not entirely correct, but the stereotype is very stable.
This article describes the results of a study of the impact of various optimizations of a virtual machine, its guest OS and application software on the results of passing the Gilev test.
Gilev’s test is a synthetic test that allows assessing the performance of the 1C: Enterprise platform. It is mainly used to evaluate performance when using a DBMS for storing 1C databases, but it can also be used for the file storage option for 1C databases. Supplied as a configuration file (* .cf) for further loading in the 1C: Enterprise configurator.
The test consists of two parts that can be run independently of each other.
First part – single-threaded test, evaluates the performance of operations in one thread, which is a characteristic feature of the 1C: Enterprise platform. Based on the test results, a bar graph is plotted, in which the current test result and the results corresponding to the ratings “poor”, “satisfactory”, “good” and “excellent” are presented from left to right. “Estimated” results have fixed values (10, 15, 35, and 60, respectively). The result of a single-threaded test is provided in certain arbitrary units.
Second part – multithreaded test, allows you to evaluate the speed of writing to disks when several queries are simultaneously accessing the database. The results are the maximum write speeds for single lines, single-stream write, maximum write speed, and the recommended number of users. When using a file storage architecture for 1C databases, this test is not available.
In addition, the test allows you to save the results to the cloud of the test authors and receive the results of other test users for comparison.
For testing in the “regular” Cloud4Y cloud, we created a virtual machine with a Windows Server 2019 guest OS. The VM was deployed from a standard template with a paravirtual disk driver. This type of controller does not offer any speed advantage over LSI Logic SAS, but is actively promoted by the vendor and may become the default controller type in the future.
Microsoft SQL Server 2019 Standard edition was used as a DBMS. The Express edition gives similar test results, but it is not applicable on real bases due to edition restrictions. Therefore, it makes no sense to use it in a virtual machine template.
A 1C: Enterprise server was installed on a virtual machine and a 1C server cluster was configured. We also installed additional administration tools for 1C servers. The Gilev test was used as the only configuration.
To test a separate configuration, where the 1C server and the DBMS are located on separate VMs, we cloned the original VM, after which we removed unnecessary components in the guest OS of each of the resulting virtual machines and carried out additional configuration.
Optimized the virtual machine… On the virtual machines used in testing, the functionality of adding virtual processors and RAM on the fly was disabled, as potentially reducing performance.
Optimized the guest OS… All optimizations were done on the basis of recommendations from the sites https://its.1c.ru and https://gilev.ru. Also, data from other thematic resources were taken into account. When making changes to the guest OS, we checked the relevance of the recommendations, since a significant part of them refers to outdated versions of operating systems. As a result, we a)completely disabled all power saving features in the guest OS and enabled the maximum performance mode, b) disabled at the system level IPv6 protocol, in the registry at HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Tcpip6 Parameters created a key DisabledComponents type DWORD (32 bits) with the meaning 0xffffffff, which corresponds to the disabling of all components of IP version 6, except for the loopback interface. This value will also use IP version 4 in prefix policies instead of IPv6.
Optimized the DBMS… In particular, we:
Installed the minimum required set of MSSQL DBMS components
We set a limit on memory consumption by the DBMS server: the minimum value is equal to half the amount of RAM, the maximum is the total size of RAM, minus 1 GB for each allocated 16 GB of RAM
Set the maximum degree of parallelism to 1
Tempdb, user database, database log were split into separate file systems on separate virtual disks
Tweaked the model and tempdb database parameters: initial database size from 1 GB to 10 GB, initial transaction log size from 1 GB to 2 GB, and auto-expanding 512 MB
The DBMS allowed volume maintenance operations
For a separate architecture, for the user on whose behalf the DBMS server was launched, the policy “Blocking pages in memory” was additionally set. For a collaborative architecture, this policy should not be used as evidenced by test results
For a joint architecture, all communication protocols were disabled, except for shared memory, for a separate one – everything except tcp
The settings are done, let’s look at what effect different infrastructure parameters fail on the test results
Impact of virtual processors and sockets
In fig. 1-3 the results of investigating the influence of sockets for the combined configuration are presented. As you can see, the maximum values are reached with one socket; as their number increases, the test results decrease.
On fig. 4 and 5 shows the merging of increasing the number of virtual processors. As you can see, an increase in the number of virtual processors does not give a significant gain in the Gilev test results.
Note: but when working with a real database and when more than one user is connected, the number of virtual processors will significantly affect the performance, and this must be taken into account.
Effect of RAM size
Now let’s evaluate the effect of the amount of RAM on the test results.
As you can see, the increase in memory does not have a tangible effect on the test results.
Note: but when working with a real database and when more than one user is connected, the amount of RAM will significantly affect performance, and this must be taken into account.
The effect of the cluster size of the file system of a volume with a database
On fig. 7-9 shows the effect of the cluster size of the file system of the volume with the database. As you can see, the cluster size of the file system does not have a tangible effect on the test results.
Note: When working with a real database, the file system cluster size can have a significant impact on performance, and this should be considered and the recommended cluster size for the available volume size should be used.
Impact of shared or split architecture
On fig. 10 presents the results of the Gilev test for a split architecture (separate DBMS server). Please note that the test does not take into account the configuration of the DBMS server in a single-threaded test, only the configuration of the server where the 1C: Enterprise platform is deployed is taken into account. In general, the performance in the Gilev test of the split architecture is slightly lower than that of the joint architecture, since the tcp protocol is used instead of the faster shared memory protocol.
Impact of cluster load and resource allocation
On fig. eleven presents the results of the Gilev test on a virtual machine located on a host isolated from the main cluster. The results are significantly higher than the previous ones, since all host resources are guaranteed to be provided to a single virtual machine.
On fig. 12 shows the test results in a shared cluster with resource assurance policies enabled. As you can see, the result is significantly lower than on an isolated host.
The test results are most influenced by disabling all possible power saving technologies in the guest operating system and the base frequency of the virtual processor
The load of the cluster in which the virtual machine is running can significantly affect the result of the Gilev test
The combined architecture gives better results than the separate one due to the use of the faster shared memory protocol. However, when using such an architecture, you need to carefully monitor the resources consumed by individual components of the system in order to avoid competition.
A significant part of the recommendations presented on the sites https://its.1c.ru and https://gilev.ru are irrelevant when using modern versions of operating systems and DBMS
I hope you find this information useful. And remember that you should not be guided by synthetic tests alone. We draw your attention to the fact that we conducted the Gilev 1C test in a virtual environment on not very powerful processors. In the future, it will be possible to conduct research on new hardware. Interesting?
What else is interesting in the blog Cloud4Y
→ Jail for the app
→ 20,000 petabytes underwater: are there any prospects for underwater data centers
→ Definitely not Windows 95: which operating systems support space?
→ We tell you about state protected services and networks
→ How to configure SSH-Jump Server
Subscribe to our Telegram-channel so as not to miss another article. We write no more than twice a week and only on business.