Problem
The same question is constantly asked on the forums: why is 1C+MSSQL slower in processing queries than the file version?
Then there is usually a “flood” of several dozen pages.
There are two popular “trends” in such forums - some say that this is normal for the client-server option, the file version should always work faster, others say that 1C does not work well with a database.
As a result of “battles and showdowns” on forums, people differ in their opinions.
We suggest breaking the question into several:
1. Does the file option work faster in “exclusive” operations, when its activities do not depend on other users in the database?
By “exclusive nature” we will understand one active (working) user in the information base.
2. Does the file option work much faster? user mode when users actively compete for resources (for example, when selling goods, they turn to warehouse balances en masse)?
3. How significant is the difference in speed between the file version and the client-server version from a business point of view?
What really
Table No. 1. Comparison of file and client-server versions of 1C
| File 1C | Client-Server 1C | |
| Maximum size of one table | 4 gb | ~hundreds of terabytes |
| Size in practice when “brakes” occur in 1C when the database volume is reached | ~16 Gb | ~500-1500 Gb |
| Number of users with comfortable 1C work | 3-10 (then table locks interfere) | 300-700 people (then you usually need to buy more powerful hardware and optimize the code again) |
| Features that eat up resources that could be spent on better performance | No |
transactional data integrity, logging of operations for further analysis, functions to increase user concurrency |
| Additional benefits | simplicity (since there are few functions) | data maintenance (eg backup) without interrupting user work |
| Minimum blocking area | Table level (less resources required) | At the record level (more resources required) |
| Cost of ownership (conditionally) | Small | Significantly more than file |
| The presence of an intermediate layer between the 1C client and the database | No | Server 1C |
Answer to the first question: Does the file option work faster in operations of an “exclusive nature”, when its activities do not depend on other users in the database - with a probability of 99% the file version is faster(provided its capabilities are not limited by unsuccessful hardware and the maximum capabilities of the file version are not achieved)!.
Don't take our word for it - check it out for yourself. Take ( detailed description here) and see for yourself (check first in the file version, then in the client-server version).
If you do not believe the test, then test the operation that you think is suitable for verification, also in the file and client-server versions. We recommend taking as a basis, for example, “closing the month” on databases up to 4 gigabytes in size (otherwise the file version may reach the size limit).
It’s clear that if closing a month using the file option is not possible for you, then it makes no sense for you to discuss the advantages of the file option, do you agree?
Another intermediate question arises:
How much faster is the file version than the client-server version in numbers?
The answer to this question is much more interesting and practical. Our test and practice show:
- on average operations on comparable volumes of data almost 2 times faster
- on average operations when data volumes begin to exceed the amount of available random access memory and increasing the pumping intensity - up to 3-4 times faster - this is just an example of closing the month
However, it is important to understand what an “average” operation is. It turns out that operations that operate on data in RAM in the client-server version do not lose, and sometimes even outperform the file version!
However, such operations are few and far between. The main load consists of operations that actually access the disk subsystem for reading, and, what is especially important, for writing data.
Moreover, even an innocuous report, when constructed, can also write data, for example, to the tempdb service database when using MS SQL Server.
When executing a request in the file version, there is no data intermediary in the form of 1C Server, i.e. one less request segment to pass through. It is logical that if, for example, you perform “work without intermediaries,” it is always faster than “working with intermediaries.” In addition, a significant part of the functionality on the DBMS side is also actually “intermediaries” - they are needed, for example, not only for executing queries, but to provide better parallelism for work of other requests - for example, to apply locks on the data used as scrupulously as possible, so as not to block “unnecessary” ones, as the file option does. It is easier to impose a lock on the entire table, since it is one record with information about the lock, and to impose locks on thousands of rows is an order of magnitude more additional records, but more importantly, it is significantly more resources spent (processor, memory, and sometimes space on disk).
In other words, the client-server option requires more resources than the file version for the same amount of work.
Hence the consequence - on the same computer you can do it IN EXCLUSIVE MODE more work in the file version than in the client-server mode (in the same exclusive mode).
As a result, it seems like the client-server option can do less work, requires more resources, but where is the “profit”, why is it used almost everywhere?
The second question of our article will help us answer: does the file version work faster in multi-user mode, when users actively compete for resources (for example, when selling goods, they access warehouse balances en masse)?
In table number 1 we see such significant disadvantages of the file option as the small size of the databases - in most enterprises, 1C databases occupy tens or hundreds of gigabytes. But more importantly, the file option imposes redundant locks (unnecessary), which significantly reduces the possibility of parallel work of users.
So, for example, an enterprise has 100 1C users. For good measure, let’s assume that each user enters 10 documents evenly throughout the day, and each tabular part contains 10 lines.
We get simple arithmetic - 100 x 10 x 10 = 10,000 lines entered into information system during the day.
For ease of understanding, we will agree that each user works with unique data, and other users do not overlap with each other either in the tabular part of the document or in the composition of the details.
In a client-server version this will work. The documents will be processed in parallel.
Knowing the redundancy of blocking in the file version, let's calculate what will happen if 100 users in the file version simultaneously enter the first document into the system that day, but press the button at the same time.
We know that the default lock timeout duration is 20 seconds. Theoretically, it can be assumed that except for the first user, all subsequent users will wait for each other for 20 seconds and then submit their documents. The total wait will be 100 users x 1 document x 20 seconds = 2000 seconds wait. You feel it - this is half an hour of user downtime.
In practice, it’s even sadder, people are not robots, they don’t see when the system is blocked or the probability of document processing is high, so they simply state that it is not possible to enter data into the system due to constant blocking. Or, more simply, in practice, the enterprise will “stop” in file mode.
But even if you imagine that an amazing programmer came to the enterprise and wrote a program so that attempts would be carried out constantly automatically, this half hour of downtime will not go away.
Moreover, if you try 2.3, the documents will worsen the picture and in a day, even with ideal code, the file version will “accumulate” 100 users x 10 documents x 20 seconds = 20,000 seconds ~ 5 and a half hours of downtime.
5 hours is a head start for the client-server option. It doesn’t even matter at what speed they will be entered in each thread in the client-server version. It is more important that they are entered, and in the file version at this time there are waits on redundant locks.
Since in addition to redundant locks there are also necessary locks, let us formulate the concept of performance again.
From a business point of view, productivity is the amount of work per day done by all 100 users, and not just one. Therefore, it is more important for a business how much data will be entered into the system by all users in total. Assessing the performance of collective work, the file version is tens to hundreds of times inferior to the client-server version.
And again we urge you not to take our word for it. Take 1C:Standard Load Test http://v8.1c.ru/expert/etp.htm or develop your own collective test and see for yourself the reliability of our statements.
If you have any questions about the test or its results, you can discuss them on the forum.
You may also want to purchase 1C:KIP, pay attention to the features.
Now let’s answer the third question: How significant is the difference in speed between the file option and the client-server option from a business point of view?
The file version is slightly ahead of the client-server version in exclusive mode and loses very significantly in multi-user mode.
But you need to understand that a business has other tasks that are almost always higher in priority, namely fault tolerance, uninterrupted operation, reliability and stability. Running a server in a failover cluster requires additional costs for data mirroring. Thus, there must always be a balance between various objectives: performance, reliability, security, etc.
The file version does not have data integrity control mechanisms. For example, if there is a network failure during data transmission, or the power goes out, then in the file version some things will be recorded and some will not. The integrity of the data will be destroyed. In the client-server version, in such cases, the incomplete transaction will simply be rolled back, and incomplete data will not enter the system, the integrity of the data will be preserved.
Those. Not only does the higher the number of users in the system, the more the file option will lose to the client-server option, but also the data recovery procedures in case of failure turn the file option into an absolutely losing option.
Now we need to ask the “right question”:
4. Why did the question arise to evaluate the difference in speed between the file and client-server options?
The same correspondence and flooding on forums begins with the fact that the questioner has performance problems in the client-server version.
But instead of studying the reasons that caused the problem in the client-server version, he discovers that there is no such problem in the file version. He is not worried that the problem may be in the “middleman”, which is missing in the file version.
The correct answer is that it doesn’t matter how much faster the file or client-server option is, but what matters is what exactly causes the slowdown in each SPECIFIC case. The word PRODUCTIVITY is dangerous, because in fact it should be described as a list of operations in the systems, which together form this productivity. It is necessary to consider each operation, starting with the one that creates the greatest contribution to slowdowns.
In general, we have been doing this professionally and successfully for many years.
We are ready to look at a specific operation that is working slowly for free and estimate the cost of solving it. If the terms and price suit you, then we speed up the operation, and if it reaches the conditions you specified, then only in this case do you pay for our work.
Users often complain that “1C 8.3 is slow”: document forms open slowly, documents take a long time to process, the program starts, reports take a long time to generate, and so on.
Moreover, such “glitches” can occur in different programs:
The reasons may be different. This is not restored holding documents, weak computer or server, the 1C server is incorrectly configured.
In this article I want to look at one of the simplest and most common reasons for a slow program - . This instruction will be relevant for users of file databases for 1-2 users, where there is no competition for resources.
If you are interested in more serious optimization of client-server options for system operation, visit the section of the site.
Where are the scheduled tasks in 1C 8.3?
Before I had time to load the program, many background tasks were completed in 1C. You can view them by going to the “Administration” menu, then “Support and Maintenance”:
Get 267 video lessons on 1C for free:
This is what the window with completed tasks looks like:
And so full list all scheduled tasks that are launched:
Among these tasks you can see such as ““, loading various classifiers, checking the relevance of the program version, and so on. For example, I have no use for almost all of these tasks. I don’t keep currency records, I control the versions myself, and load classifiers as needed.
Accordingly, it is in my (and in most cases in your) interests to disable unnecessary tasks.
Disabling routine and background tasks in 1C 8.3
How to speed up work in 1C: Accounting 8.3 (edition 3.0) or disable routine and background tasks
2019-01-15T13:28:19+00:00Those of you who have already switched to the new edition of 1C: Accounting 8.3 (edition 3.0) have noticed that it has become slower than 2. Some strange slowdowns, endless background tasks several times a day, which no one asked her to perform without our knowledge.
My accountants told me immediately after the transition that the new edition of 1C: Accounting 3.0 is downright slow compared to the previous ones! And it’s simply impossible to work.
I started to look into it and very soon found out that the main reason for freezes and subsequent user dissatisfaction are regulatory and background jobs, many of which are enabled by default, although for the vast majority of accountants there is no need for them.
Well, for example, why do we need to run the “Text Extraction” task a hundred times a day if we do not carry out a full-text (accountants, don’t be alarmed) search across all objects in our database.
Or why constantly download currency rates if we do not have currency transactions or we do them occasionally (and before that we ourselves can click the download rates button).
The same applies to 1C’s constant attempt to connect to the site and check and update bank classifiers. For what? I myself will press the button to update the classifiers if I don’t find the right bank by its BIC.
How to do this step by step below.
1. Go to the "Administration" section and select "Maintenance" () in the action panel:
2. In the window that opens, find and select “Routine and background tasks”:
3. Open each task that has "On" in the "On" column. there is a daw.
4. Uncheck "Enabled" and click the "Save and Close" button.
5. Do this with each of the included tasks and enjoy the new edition. Overall, in my opinion, it is much better than two.
At the same time, the platform will still enable some of the scheduled tasks you disabled.
1C:Enterprise programs, which have become the leader in automation, are increasingly being integrated into the business and enterprise network. The 8th version of the program is no longer intended only for accounting and has long gone beyond the limits of one or two computers. Its capabilities are increasingly being used not only by managers to control financial transactions, but also by CRM managers, storekeepers for warehouse accounting, etc.
In this regard, the load on local computer network enterprises and to the computer center - the server on which the 1C databases are located. Understanding this, the developer has provided several options for deploying 1C:Enterprise programs - file and client-server.
File version 1C: pros and cons
The simplest and cheapest option for deploying the 1C:Enterprise 8 platform is the file option. Many people make the mistake of saying that it is not suitable for multi-user networking. Not at all, this work option can be used for work by one user without network versions, and for sharing up to 5 clients. To configure the operation of the 1C file version, you can use a simple computer on which the directory is “shared” (access to shared folder), which actually contains one single file with the database. Naturally, this computer must be constantly turned on for users to have access to the database. The second not very pleasant moment is full access all users working with the program to this shared folder, i.e. each of them can not only work with 1C, but also have the opportunity to copy this database to their computer (flash drive, removable disk, etc.) or simply delete it. This suggests the conclusion that it is impossible to control the safety of data in a large company. And of course, one cannot help but say that when using the file version of 1C deployment, all calculations and operations are performed on the client’s computer, so workstations must have a good supply of computing power: powerful processor and sufficient RAM. And at the current dollar exchange rate, not everyone can afford it, considering, moreover, that with the release of each new version Program requirements for hardware are only becoming higher.
A significant advantage can be considered the almost zero costs for server part- it can be served by a simple powerful computer, where, for example, the chief accountant works with good hard disk and network card throughput 1GB/s. Even regular (non-server) operating systems will provide up to 5 connections from 1C clients. Backup is also quite simple, which, by the way, is latest versions can be customized regular means 1C itself.
Client connections to file 1C
For users to work with the file server version of 1C:Enterprise, there are 2 options: “thick client” and web client. The first option is the simplest; it is the one used in local versions and is not worthy of much attention. But when using the web client, you need to install software practically absent. To work in this mode, you only need a compatible web browser, which can be launched on almost any platform and even on a tablet via 3G Internet. Of course, you will have to complicate the setup a little, since you will need a web server in addition to the file server, but this will bring a lot of advantages:
- work on any device and any operating system(MacOS, Linux, Windows, Android tablet, etc.);
- work from any place where there is Internet (of course, with appropriate settings);
- there is no need to install and update software on workstations.
General points for deploying file server 1C
The issue of licensing cannot be avoided: to connect each client, regardless of the type of connection, in addition to the program itself, you must purchase a client license for access by a simultaneously working user. This can be either a hardware key (USB token) or a software PIN code.
In the next part of the article, I will dwell in detail on the client-server version of 1C:Enterprise, the pros and cons of this approach, and options for saving on software.
This raised several questions about 1C operating modes.
Operating modes with information base:
File version of work
Client - server version of work
File mode of operation
The file version of the work is designed for personal work of one user, but multi-user work over the network is also available. Parallel processing of documents in this mode is impossible. On average, about 10 users can work simultaneously in file mode.
No server key purchase required.
In the file mode of operation, the entire information base (database, configuration) is stored in a file 1Cv8.1CD.
1Cv8.1CD is a File Database
The file database (file 1Cv8.1CD) is managed by the File DBMS, which is part of the 1C:Enterprise platform.
In the file mode of operation, the client-server mode of operation is simulated, so you still need to adhere to the client-server development mechanism.
If the 1Cv8.1CD file exceeds 4 GB. Now is the time to think about switching to a client-server version of work.
The big disadvantage of the file mode of operation is low information security.
Scheme of work in the file version
The thick client application directly accesses the infobase and receives a response. The thin client also accesses the database directly using its own protocol. Web client accesses the information base with using the Web server.
To switch from file mode to client-server It is enough to download the information base in dt format and then upload it to the information base created on the server.
Client-server version of work
The client-server option is suitable for working with the information base of a large number of users. The reliability of the database is guaranteed by the DBMS, which contains automatic archiving and recovery mechanisms. The speed of working with data is higher than in file mode.
The client-server version operates on a three-tier architecture:
User
Application server (server cluster)
DBMS
Clients contact the cluster manager, which redirects the user's request to some working server (the request can be redirected to a freer server). Next, the server turns to the DBMS to obtain the necessary data.
The DBMS processes the request and returns a data array to the server, which returns the processed data to the client. In a server cluster, it is possible to configure backup servers to which processes are transferred if the working server fails. This increases reliability.
The web client interacts (via the http protocol) with a web server that accesses a cluster of servers. It is also possible to operate a thin client using the http protocol (according to exactly the same scheme)
Current operating mode can be viewed in the configurator and in user mode by opening Help -> About the program (line “mode”)
A regular application always runs in thick client mode. A managed application can run in both a thick and thin client. The functionality of the thin client is very limited.
Article about regular and managed applications, regular and controlled forms"1C:Enterprise", located here.
Please leave your comment, I value your opinion.
P.S. Charlie Brooker - Wish Box
Loading...
