• Choosing server-side hardware for 1C:Enterprise system
• Choosing server-side hardware for 1C:Enterprise system
• Choosing server-side hardware for 1C:Enterprise system

Choosing server-side hardware for 1C:Enterprise system

Task definition and prerequisites

Planning the deployment of 1C:Enterprise system (referred to below as “Target System” or TS) we need to choose the servers powerful enough for the workload expected. At the same time we don’t want to waste money buying excessively powerful servers you don’t need at that time.

In other words, we need to choose the hardware with performance that is necessary and sufficient (or a bit more that that) for the target 1C:Enterprise system operation to meet the users requirements.

Target System

Before you start choosing the hardware you need to know all characteristics of the Target System (TS):

• Application. You have to have fully functional application to be used in Target System (TS).
• TS workload characteristics. You need to know how many users are to work with TS, what kind of actions they are to perform, what are the every action parameters (like number of lines in tabular part of a document or specific report settings) and how often the actions are to be performed.
• Other characteristics:
  • DBMS to be used (including version number and main settings)
  • Operating systems of server and client-side computers.
  • 1C client type, etc.

You can use the procedure below having limited notion of some TS characteristics but it can compromise the calculations accuracy.

Model System

The main concept of the procedure is to measure the hardware utilization on so-called model system (MS) and then linearly extrapolate it to the TS. Then you have to choose the hardware capable of handling with the workload you just calculated.

Model system is a live system identical with TS except the workload characteristics. Among other things MS has to:

• Work with the same application
• Work in the same applied solution mode (file mode, client/server mode)
• Have the same number of work servers and identical layout of system components;
• Have the same 1C:Enterprise, DBMS and OS versions

You need the MS to work on the real hardware, which characteristics are well known and will be used to calculate the characteristics of the TS hardware.

Below is the description of various types of the MS you can use.

Single User Test Model System

You can emulate the MS workload, performing user actions manually using any hardware you have on hand. You need to measure the utilization of the hardware components produced be every action and then calculate the overall utilization.

Use case: initial (rough) hardware characteristics calculation during the pre-sale stage of the project. Before the client is ready to sign the agreement, he asks you to give him an estimate of the hardware he is going to need. You want it done without allocation too many resources on it, given that the project isn’t started yet.

Pros:

• Relatively fast procedure (typically 1-3 days)
• No need for powerful and expensive hardware
• No need for real users participation

Cons:

• Relatively low accuracy of the result
• Relatively high complexity of the procedure
• Need for manual execution of a great number of routine actions

Multi-user model systems

Using the single user test system you measure the utilization of hardware components produced by every single operation and than calculate the overall utilization. Instead you can measure the utilization on multi-user system as it is.

Test system

Using Test-center application you can emulate multi-user activity without real users. This test development and preparation is a time consuming task but you can use it not only for hardware characteristics calculation but also for other purposes like:

• Analysis and fixing the performance and lock issues occurring only in concurrent (i.e. multi-user) environment
• Load testing before changing system parameters (like platform or application version, hardware upgrade etc.).

Use case: preparing the system to go live. The agreement is signed and all necessary functionality is developed. Before system goes live you need to choose an appropriate hardware and make sure that its performance meets client’s requirements.

Pros:

• Higher accuracy and simplicity of the calculation
• The test can be used for various tasks

Cons:

• Time consuming task (usually more than 1 month)
• You need to use hardware powerful enough to cope with the test workload.

Your Live System

If your system is already put into trial or working operation (i.e. there are real users working with the system on daily basis) you can use the system as a model.

Use cases:

• You system is on the trial operation stage. It works on the temporary hardware and there is limited number of users working with it. You goal is to figure out what hardware you are going to need for the system to operate under full workload.
• System is in working operation and you expect an increase of the number of users. You need to know what hardware you are going to need down the road.

Pros: Best accuracy without much effort

Cons: You need a real users participation to have the job done

Comparable live system

If your system hasn’t been deployed yet, but you have an access to somebody else’s comparable system, you can use it as a model.

Use case: You are planning 1C application deployment and you are aware of the similar system working in another company.

Pros: Quick and simple procedure

Cons:

• Calculation accuracy will depend on the MS parameters proximity to your system’s parameters
• You have to get an access to some parameters and elements of MS, which can be challenging managerial task.

Model System Type Selection

Below is the summary table giving you all options along with their assessment in terms of complexity, accuracy and so on.

	Single-user test system	Multi-user model systems
		Test system	Your live system	Somebody else’s live system
Efforts	Insignificant	Massive	Little	Little
Hardware capacity	Any	Significant	None	None
Procedure complexity	High	Low	Low	Low
Procedure accuracy	Low	Average	High	Decent
Need for real users	No	No	Yes	Yes

On the starting stages of the project (when you don’t have real users working with the system) you want to use a test (single or multi-user) system as MS. Using single-user test system you get less accurate calculation in literally no time. Using multi-user test system you spend significant amount of time but the result is much more accurate. Moreover, you can use the same multi-user test to perform many other tasks.

If you system isn’t deployed yet but you are aware there is a similar system working in other company, you can use it as MS.

If your system is already live, you want to use it as MS. That gives you the most accurate results without much time spent on calculation.

Hardware Characteristics Calculation

The basic concept is to measure hardware utilisation on the model system and linearly extrapolate it into the target system, which gives you TS hardware workload estimate. Having this done you can choose the hardware able to cope with the workload you calculated.

You should calculate the workload of particular TS server basing on the utilisation of correspondent MS server: DBMS server of TS – basing on DBMS server of MS and so on.

If your system has well-expressed workload patterns (as it happens, for instance, in HR systems) you should make the calculation for every pattern and choose the maximum. Say, calculated CPU cores number for the pattern "regular work during the month" is 4 whereas the same characteristic for the "payroll accounting" pattern is 16. In this case you should choose 16 as a final result.

Here is a list of hardware characteristics affecting the performance of the system most of all:

• CPU performance
• Disk array performance
• RAM size

The procedure described below allows you to determine these characteristics for server-side hardware of your system.

CPU

The procedure consists of the following steps:

• Calculation of the nominal number of CPU cores
• CPU model selection
• CPU number calculation

The procedure should be repeated for every server of TS.

Calculation of the nominal number of CPU cores

Using multi-user model systems

Please, use the Excel workbook – sheet "Multi-user MS", table "Nominal number of CPU cores. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values with your data specifying the following:

• Average number of active users of the model system (D3)
• Average number of active users of the target system (D4)
• Overall number of CPU cores on model server (B10-B11)
• Average percentage of elapsed time that the processor spends (C10-C11)

Nominal number of CPU cores will be calculated in D10-D11 cells. After that you need to choose the processor model and recalculate the nominal CPU cores number into CPU number.

See also: calculation formula.

Using single-user test model system

The procedure for single-user test model system consists of the following steps:

• Make a list of user actions. You need a list of key user actions along with every action frequency (number of executions per hour).
• Get "%Processor time" for every action. You need to logon into the test system as a real user (to enable access restrictions) and perform manually every action from the list. You need to register and save to a separate file a "%Processor time" counter value during each action execution.
• Calculate nominal CPU cores number, for every action and summarize the data across the list. Use the Excel workbook – sheet "Single-user test MS", table "Nominal number of CPU cores. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values with your data specifying the following:
• Name of the user action (A9, A10…)
• Start time of the user action to the seconds (B9, B10…)
• End time of the user action to the seconds (C9, C10…)
• The number of the actions performing by all system users per hour (D9, D10…)
• The overall number of CPU cores of the model server (B2)
• Average percentage of elapsed time that the processor spends (E9, E10…)

Nominal amount of the CPU cores will be calculated in F25 cell. After that you need to choose the processor model and recalculate the nominal CPU cores number into CPU number.

See also: calculation formula.

Choosing the processor model

When you choose the processor model you need to take into account not only the number of cores but also single-thread performance of a core.

Basic idea: choose the processor with equal or greater single-thread performance than the processor of the model system.

The most solid way to do the right choice is to pick the processor meeting all the requirements listed below:

• Of the same make as the MS processor
• Targeted to the same type of tasks
• Belonging to the same or more recent generation
• Having equal or greater clock frequency

If there are no options available you can pick a processor of any other type, but you need to assure it has the same or greater single-thread performance than the model system processor. You can compare single-thread performance of two different processors using vendor recommendations or independent benchmark data.

CPU number calculation

Nominal CPU cores number you have calculated is a non-integral number. You need to round it up and calculate a number of CPUs of the processor model you have selected.

Say, you have got nominal CPU number equal to 9.12 and have selected a CPU model having 4 cores. In fact your server will be powerful enough (for your purposes) if it has 10 cores overall, but there is only 4-cores CPUs so it’s impossible. The closest multiple of 4 which is greater than 10 is 12 which gives you a CPU number equal to 3. But there are no servers with odd CPU number available, so you have to choose a 4-CPU server, which gives you 16 cores instead of 10.

Another option is to deploy your system on a virtual rather than physical server. In this case you can allocate an exact number of CPU cores you need.

Disk array

The procedure consists of the following steps:

• Relative disk array performance calculation
• Disk array model selection

The procedure should be repeated for every server of TS.

Relative disk array performance calculation

Multi-user model system

Use the same Excel workbook – sheet "Multi-user MS", table "Relative performance of the disk array. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values (B18-19, C18-19) with percent id idle time of the disk array.

Relative performance of the TS disk array will be calculated in C17-18.

Having this done you need to choose disk array model.

See also: calculation formula.

Single-user test system

Follow the same procedure you used for calculation of nominal CPU cores number. Note that the sample list of user actions in the table is the same as the list used for CPU cores number calculation. It means that using single-user test model system you want to run every operation once registering all necessary performance counters at the same time.

Having this done you need to choose disk array model.

See also: calculation formula.

Choosing the disk array model

TS disk array relative performance is a coefficient you need to multiply the MS disk array performance by to get the performance you need. For example, having relative TS disk array performance equal to 2.46 means that you need twice and a half more powerful array comparing to the MS. Sometimes relative performance can be less than 1 which means that MS disk array performance is excessive for you target system.

Disk array performance is a function of its input-output capacity, i.e. the amount of data it can process (read or write) per time unit. There are too much factors that might influence the result disk array performance, so we cannot offer a way to "calculate" its model. You need to use empirical data instead.

Here is the list of the possibilities you have:

Vendor recommendation. You know the model of MS disk array as well as relative performance of the array you are looking for. You can ask a vendor to choose an array according to these requirements. The request might sound like "we need an array working 3 times faster than the array such-and-such in such-and-such configuration".

Benchmark comparison charts. Some vendors, as well as independent organisations, compare the performance of different disk arrays and publish the results online. If you find you MS array in one of those comparison chart you can pick the TS array from the rest of the list. Abundant examples of comparisons of that kind can be found on the Internet using query like "disk array performance comparison"

You own performance test. You can compare MS and TS disk arrays performance on your own if you have an access to both systems. Say, vendor cannot take a responsibility for the array choice but can provide you with an access to the assortment available, so you can make a comparison. There are a number of free and paid benchmark tools, which allow you to get the job done. Here is an example of two DBMS server disk arrays comparison using MS SQLIO tool. Choosing the disk array you also need to keep in mind its fault tolerance, which is achieved usually by means of redundancy (and higher price per one Kb stored). RAM size RAM size calculation procedure significantly differs depending on the model system type and the server role. RAM size calculation Multi-user model system Working server of 1C:Enterprise cluster Source data for the calculation is an overall size of RAM allocated by all 1C:Enterprise processes running on this MS server. You should register and summarize the RAM allocated during the peak workload hours for the following processes:

ragent

rmngr (if it’s running on the server)

rphost (there can be more then one rphost process on the same server) For the servers working under Windows you should obtain the memory usage basing on the Task Manager data (Memory column). For Linux servers you can use "pmap" command. Put the overall amount of memory allocated into B25 cell on the sheet "Multi-user MS" of the Excel file. The result (RAM size for the correspondent 1C:Enterprise working server) will be calculated in C25 cell. DBMS server 1C:Enterprise cluster processes allocate exactly as much memory as they need. Therefore we always can use this amount of RAM as a base for the calculation. In contrast, DBMS server can make do with as little memory as available now. In other words, the amount of memory allocated by DBMS server can be smaller than it is necessary to coping with current DBMS workload. Therefore, you can use amount of memory allocated by MS DBMS server only when you are sure it works without shortage of memory. To check the condition you can use Cache Hit Ratio counter, which reflects the relative number of queries getting data from cache (instead of the database itself). This counter has to be above 80%, i.e. at least 80% of all data has to be read from the cache. If you use MS SQL Server you can obtain the counter value by Performance Monitor (SQL Server:Buffer Manager \ Buffer Cache Hit Ratio). All DBMS working with 1C provide the counter in one form or another. Please, refer to the documentation on the DBMS you use. If Cache Hit Ratio of MS DBMS server is greater of equal to 80%, summarize memory allocated by all DBMS processes and put the sum into B26 cell of "Multi-user MS" sheet of the Excel file. The result (RAM size for TS DBMS server) will be calculated in C26 cell. If Cache Hit Ratio of MS DBMS server is than 80%, DBMS works under memory pressure, which impairs overall system performance. In this case you can use the counter "Target Server Memory" available in some DBMS. For instance, you can get it for MS SQL Server using Performance Monitor (SQL Server:Memory Manager \ Target Server Memory). Please, refer to the documentation on the DBMS you use. Put "Target Server Memory" value into B26 cell of "Multi-user MS" sheet of the Excel file. The result (RAM size for TS DBMS server) will be calculated in C26 cell. If your DBMS doesn’t support this counter you should calculate the RAM size for DBMS server basing on the RAM size for 1C server. Allocate 4 times more RAM for DBMS against overall RAM size on all 1C working servers. Please note, that you get only rough estimate using this method. Single-user test system There is no way to calculate RAM size without multi-user model system. If you don’t have one you should allocate 8 Gb RAM for 1C:Enterprise server and 24 Gb for DBMS server for every 100 users. This method most probably will give you an overestimate, so you are going to be on the safe side with these characteristics (but spend some extra for the performance you don’t really need). To calculate RAM size you can use the table "RAM size" of the "Single-user test MS" sheet of the Excel file. Put the number of users in B52 cell. Required RAM size will be calculated in B53 and B54 cells. Appendices %Processor Time You should collect "%Processor Time" counter for at least one hour of continuous users activity period. Do not use counter values collected over the period including intervals of untypically low workload, like lunch or nighttime. For Windows servers use "Processor [_Total] \ %Processor Time" counter of Performance Monitor. For Linux servers use an average value of the "us" column of the "vmstat" command output. The Start and the end points of the user action Calculating your hardware characteristics using single-user test MS you need to estimate an average utilisation of the hardware components during each action. To avoid underestimation you want to follow up the procedure:

• Prepare your test until it’s one click away of the action start. For instance, if you are estimating a document posting time, you need to open a form and fill up all documents fields, so the only thing left to do is "Post" button click.
• Start performance-measuring tool (for instance, Performance Monitor) and get it ready (add counters, turn collecting on)
• Execute the user action
• Pause the performance-measuring tool and save the result into a stand-alone file with a unique name.

After you execute all user actions you need to transfer the data you collected into the Excel file. Please be cautious of choosing the precise start and end points of the user action for it can significantly affect the calculations result. Say, one of the actions performance chart looks like that: Note, that the data includes not only user action but also some time before it starts and after it ends. For the calculation you need only the central part of the chart. This gives you the following values:

• Action start time - 5:04:24
• Action end time - 5:04:29
• %Processor time – 99.213%

Note that %Processor Time according to the first chart is almost twice as little (38.096%) and the period of time is considerably longer. If you use these values the results will be significantly underestimated. CPU cores calculation formula for multi-users MS tCPU = mCPU *mPT/100/mU*tU, where

• tCPU – the number of the cores of the target server
• mCPU – the number of the cores of the model server
• mPT – %Processor Time of the model server
• tU – the number of active users if the target system
• mU – the number of active users if the model system

%Processor Time of the MS (mPT) shows how much time (in percent) the entire processor (including all its cores) was busy working under the workload. Multiplying this value to the number of cores we get the nominal utilisation of one core. For instance, given mPT = 25% and mCPU = 4 we get an equivalent of 100% of utilisation for one core. In other words 25% utilisation if 4-cores processor is the same thing as 100% utilisation of 1-core processor. Dividing this by 100 we will get the nominal number of cores fully utilised under this workload. In our example the number is 1. That said, the nominal number of CPU cores used in MS is equal to mCPU *mPT/100. This workload was created by mU users of the model server. So the average workload created by one user is mCPU *mPT/100/mU. Basing on premise that MS and TS users produce the same workload we get the following formula for the nominal number of CPU cores fully utilised in the target server: mCPU *mPT/100/mU*tU. CPU cores calculation formula for single-users test MS tCPU =  where tCPUn – calculated utilization of processor for nth user action, which in turn calculated using the following formula: tCPUn = (tF - tS) * tFREQn * mPTn * mCPU * 0.24, where

• tS and tF – action start and end time respectively
• tFREQn – action frequency (overall number of the action execution by all users of TS per hour)
• mPTn – %Processor Time of the model server during the execution of the action
• mCPU – CPU cores number of model server

Excel stores date-time values as a number of days since 1.1.1900 where time is represented by the fractional part of the number. Therefore the user action duration is calculated as (tF - tS) * 86400. Average CPU utilization during this period of time is mPTn percent. In other words there were mPTn / 100 * mCPU cores fully utilized for that time. Distributing this utilization evenly for one hour we get the following: (tF - tS) * 86400 *  mPTn / 100 / 3600 * mCPU = (tF - tS) * mPTn * mCPU * tFREQn. Multiplying this to mFREQn (action frequency) we get: (tF - tS) * tFREQn * mPTn * mCPU * 0.24 Idle time of disk array (%) You should collect disk idle time counters for at least one hour of continuous users activity period. Do not use counter values collected over the period including intervals of untypically low workload, like lunch or nighttime. Important! Before you start collecting the disk utilization data you need to make sure there is no RAM shortage on the model server. Use "Memory / Available Mbytes" for Windows and "free" command for Linux. Free RAM available shouldn’t be under 500 Mb. For Windows servers you need to use "Physical Disk [_Total] \ %Idle Time". For Linux servers use an average value of the 100 - "%util " column of the " iostat – d -x " command output. Relative disk array performance calculation for multi-user MS tRDP = (100 - mDIdle) / 100 * tU / mU, where

• tRDP – relative performance of the TS disk array
• mDIdle – MS disk array %idle time
• tU – average number of active users of TS
• mU – average number of active users of MS

Disk %utilization time = 100 – disk array %idle time. Express the disk utilization as a unit fraction we get (100-mDUtil) / 100. This workload is created by tU users, therefore one user creates an average of (100-mDUtil) / 100 / mU nominal disk arrays utilization. Basing on premise that MS and TS users utilize disks to the same extent, we get the relative performance of TS disk array = (100-mDUtil) / 100 * tU / mU. Relative disk array performance calculation for single-user test MS tDU =  where tDUn – calculated utilization of the disk array during execution of nth user action, which can be calculated using the following formula: tDUn = (tF - tS) * mFREQn * mDUn * 0.24, where

• tS and tF – action start and end time respectively
• mFREQn – action frequency (overall number of the action execution by all users of TS per hour)
• mDUn – MS disk array average utilization during the execution of the action

Relative utilization of the disk array during this period of time is mDUn / 100. Distributing this utilization evenly for one hour we get the following: mDUn / 100 * (tF - tS) * 86400 / 3600 = mDUn * (tF - tS) * 0.24. Multiplying this to mFREQn (action frequency) we get: (tF - tS) * mFREQn * mDUn * 0.24 Comparing disk array performance using SQLIO Important! Before running the test you need to make sure that there is no side workload in the system, otherwise you can get distorted results. Download and install sqlio.msi. Download and decompress the archive in the same folder the sqlio was installed to. Run sqlio.bat. You need to repeat the procedure on both model and target computers. As a result of the test, which lasts for about 20 minutes, there will be 6 files created: Reads_1.txt, Reads_2.txt, Reads_3.txt, Writes_1.txt, Writes_2.txt, Writes_3.txt. Files contain results of disk array performance testing in a text format. To estimate if the target disk array meets your system performance requirements, you need to open the files with any text editor and transfer the data to  "SQLIO" sheet of the Excel file. The table is filled out with sample data taken from these files. You need to replace them with your data. You also need to fill B4 and B5 cells with relative target disk performance calculated on the previous step. Calculated columns "Comparison" will show the target and model performance characteristic ratio. If the ratio is not less than correspondent relative performance (i.e. target disk array outperforms model disk array to the necessary extent) the cell will be filled with green. If the ratio is worse than you need, the cell will be filled with red. If means, the performance of target disk array could not meet the requirements of your system.

Choosing server-side hardware for 1C:Enterprise system

Task definition and prerequisites

Planning the deployment of 1C:Enterprise system (referred to below as “Target System” or TS) we need to choose the servers powerful enough for the workload expected. At the same time we don’t want to waste money buying excessively powerful servers you don’t need at that time.

In other words, we need to choose the hardware with performance that is necessary and sufficient (or a bit more that that) for the target 1C:Enterprise system operation to meet the users requirements.

Target System

Before you start choosing the hardware you need to know all characteristics of the Target System (TS):

• Application. You have to have fully functional application to be used in Target System (TS).
• TS workload characteristics. You need to know how many users are to work with TS, what kind of actions they are to perform, what are the every action parameters (like number of lines in tabular part of a document or specific report settings) and how often the actions are to be performed.
• Other characteristics:
  • DBMS to be used (including version number and main settings)
  • Operating systems of server and client-side computers.
  • 1C client type, etc.

You can use the procedure below having limited notion of some TS characteristics but it can compromise the calculations accuracy.

Model System

The main concept of the procedure is to measure the hardware utilization on so-called model system (MS) and then linearly extrapolate it to the TS. Then you have to choose the hardware capable of handling with the workload you just calculated.

Model system is a live system identical with TS except the workload characteristics. Among other things MS has to:

• Work with the same application
• Work in the same applied solution mode (file mode, client/server mode)
• Have the same number of work servers and identical layout of system components;
• Have the same 1C:Enterprise, DBMS and OS versions

You need the MS to work on the real hardware, which characteristics are well known and will be used to calculate the characteristics of the TS hardware.

Below is the description of various types of the MS you can use.

Single User Test Model System

You can emulate the MS workload, performing user actions manually using any hardware you have on hand. You need to measure the utilization of the hardware components produced be every action and then calculate the overall utilization.

Use case: initial (rough) hardware characteristics calculation during the pre-sale stage of the project. Before the client is ready to sign the agreement, he asks you to give him an estimate of the hardware he is going to need. You want it done without allocation too many resources on it, given that the project isn’t started yet.

Pros:

• Relatively fast procedure (typically 1-3 days)
• No need for powerful and expensive hardware
• No need for real users participation

Cons:

• Relatively low accuracy of the result
• Relatively high complexity of the procedure
• Need for manual execution of a great number of routine actions

Multi-user model systems

Using the single user test system you measure the utilization of hardware components produced by every single operation and than calculate the overall utilization. Instead you can measure the utilization on multi-user system as it is.

Test system

Using Test-center application you can emulate multi-user activity without real users. This test development and preparation is a time consuming task but you can use it not only for hardware characteristics calculation but also for other purposes like:

• Analysis and fixing the performance and lock issues occurring only in concurrent (i.e. multi-user) environment
• Load testing before changing system parameters (like platform or application version, hardware upgrade etc.).

Use case: preparing the system to go live. The agreement is signed and all necessary functionality is developed. Before system goes live you need to choose an appropriate hardware and make sure that its performance meets client’s requirements.

Pros:

• Higher accuracy and simplicity of the calculation
• The test can be used for various tasks

Cons:

• Time consuming task (usually more than 1 month)
• You need to use hardware powerful enough to cope with the test workload.

Your Live System

If your system is already put into trial or working operation (i.e. there are real users working with the system on daily basis) you can use the system as a model.

Use cases:

• You system is on the trial operation stage. It works on the temporary hardware and there is limited number of users working with it. You goal is to figure out what hardware you are going to need for the system to operate under full workload.
• System is in working operation and you expect an increase of the number of users. You need to know what hardware you are going to need down the road.

Pros: Best accuracy without much effort

Cons: You need a real users participation to have the job done

Comparable live system

If your system hasn’t been deployed yet, but you have an access to somebody else’s comparable system, you can use it as a model.

Use case: You are planning 1C application deployment and you are aware of the similar system working in another company.

Pros: Quick and simple procedure

Cons:

• Calculation accuracy will depend on the MS parameters proximity to your system’s parameters
• You have to get an access to some parameters and elements of MS, which can be challenging managerial task.

Model System Type Selection

Below is the summary table giving you all options along with their assessment in terms of complexity, accuracy and so on.

	Single-user test system	Multi-user model systems
		Test system	Your live system	Somebody else’s live system
Efforts	Insignificant	Massive	Little	Little
Hardware capacity	Any	Significant	None	None
Procedure complexity	High	Low	Low	Low
Procedure accuracy	Low	Average	High	Decent
Need for real users	No	No	Yes	Yes

On the starting stages of the project (when you don’t have real users working with the system) you want to use a test (single or multi-user) system as MS. Using single-user test system you get less accurate calculation in literally no time. Using multi-user test system you spend significant amount of time but the result is much more accurate. Moreover, you can use the same multi-user test to perform many other tasks.

If you system isn’t deployed yet but you are aware there is a similar system working in other company, you can use it as MS.

If your system is already live, you want to use it as MS. That gives you the most accurate results without much time spent on calculation.

Hardware Characteristics Calculation

The basic concept is to measure hardware utilisation on the model system and linearly extrapolate it into the target system, which gives you TS hardware workload estimate. Having this done you can choose the hardware able to cope with the workload you calculated.

You should calculate the workload of particular TS server basing on the utilisation of correspondent MS server: DBMS server of TS – basing on DBMS server of MS and so on.

If your system has well-expressed workload patterns (as it happens, for instance, in HR systems) you should make the calculation for every pattern and choose the maximum. Say, calculated CPU cores number for the pattern "regular work during the month" is 4 whereas the same characteristic for the "payroll accounting" pattern is 16. In this case you should choose 16 as a final result.

Here is a list of hardware characteristics affecting the performance of the system most of all:

• CPU performance
• Disk array performance
• RAM size

The procedure described below allows you to determine these characteristics for server-side hardware of your system.

CPU

The procedure consists of the following steps:

• Calculation of the nominal number of CPU cores
• CPU model selection
• CPU number calculation

The procedure should be repeated for every server of TS.

Calculation of the nominal number of CPU cores

Using multi-user model systems

Please, use the Excel workbook – sheet "Multi-user MS", table "Nominal number of CPU cores. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values with your data specifying the following:

• Average number of active users of the model system (D3)
• Average number of active users of the target system (D4)
• Overall number of CPU cores on model server (B10-B11)
• Average percentage of elapsed time that the processor spends (C10-C11)

Nominal number of CPU cores will be calculated in D10-D11 cells. After that you need to choose the processor model and recalculate the nominal CPU cores number into CPU number.

See also: calculation formula.

Using single-user test model system

The procedure for single-user test model system consists of the following steps:

• Make a list of user actions. You need a list of key user actions along with every action frequency (number of executions per hour).
• Get "%Processor time" for every action. You need to logon into the test system as a real user (to enable access restrictions) and perform manually every action from the list. You need to register and save to a separate file a "%Processor time" counter value during each action execution.
• Calculate nominal CPU cores number, for every action and summarize the data across the list. Use the Excel workbook – sheet "Single-user test MS", table "Nominal number of CPU cores. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values with your data specifying the following:
• Name of the user action (A9, A10…)
• Start time of the user action to the seconds (B9, B10…)
• End time of the user action to the seconds (C9, C10…)
• The number of the actions performing by all system users per hour (D9, D10…)
• The overall number of CPU cores of the model server (B2)
• Average percentage of elapsed time that the processor spends (E9, E10…)

Nominal amount of the CPU cores will be calculated in F25 cell. After that you need to choose the processor model and recalculate the nominal CPU cores number into CPU number.

See also: calculation formula.

Choosing the processor model

When you choose the processor model you need to take into account not only the number of cores but also single-thread performance of a core.

Basic idea: choose the processor with equal or greater single-thread performance than the processor of the model system.

The most solid way to do the right choice is to pick the processor meeting all the requirements listed below:

• Of the same make as the MS processor
• Targeted to the same type of tasks
• Belonging to the same or more recent generation
• Having equal or greater clock frequency

If there are no options available you can pick a processor of any other type, but you need to assure it has the same or greater single-thread performance than the model system processor. You can compare single-thread performance of two different processors using vendor recommendations or independent benchmark data.

CPU number calculation

Nominal CPU cores number you have calculated is a non-integral number. You need to round it up and calculate a number of CPUs of the processor model you have selected.

Say, you have got nominal CPU number equal to 9.12 and have selected a CPU model having 4 cores. In fact your server will be powerful enough (for your purposes) if it has 10 cores overall, but there is only 4-cores CPUs so it’s impossible. The closest multiple of 4 which is greater than 10 is 12 which gives you a CPU number equal to 3. But there are no servers with odd CPU number available, so you have to choose a 4-CPU server, which gives you 16 cores instead of 10.

Another option is to deploy your system on a virtual rather than physical server. In this case you can allocate an exact number of CPU cores you need.

Disk array

The procedure consists of the following steps:

• Relative disk array performance calculation
• Disk array model selection

The procedure should be repeated for every server of TS.

Relative disk array performance calculation

Multi-user model system

Use the same Excel workbook – sheet "Multi-user MS", table "Relative performance of the disk array. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values (B18-19, C18-19) with percent id idle time of the disk array.

Relative performance of the TS disk array will be calculated in C17-18.

Having this done you need to choose disk array model.

See also: calculation formula.

Single-user test system

Follow the same procedure you used for calculation of nominal CPU cores number. Note that the sample list of user actions in the table is the same as the list used for CPU cores number calculation. It means that using single-user test model system you want to run every operation once registering all necessary performance counters at the same time.

Having this done you need to choose disk array model.

See also: calculation formula.

Choosing the disk array model

TS disk array relative performance is a coefficient you need to multiply the MS disk array performance by to get the performance you need. For example, having relative TS disk array performance equal to 2.46 means that you need twice and a half more powerful array comparing to the MS. Sometimes relative performance can be less than 1 which means that MS disk array performance is excessive for you target system.

Disk array performance is a function of its input-output capacity, i.e. the amount of data it can process (read or write) per time unit. There are too much factors that might influence the result disk array performance, so we cannot offer a way to "calculate" its model. You need to use empirical data instead.

Here is the list of the possibilities you have:

Vendor recommendation. You know the model of MS disk array as well as relative performance of the array you are looking for. You can ask a vendor to choose an array according to these requirements. The request might sound like "we need an array working 3 times faster than the array such-and-such in such-and-such configuration".

Benchmark comparison charts. Some vendors, as well as independent organisations, compare the performance of different disk arrays and publish the results online. If you find you MS array in one of those comparison chart you can pick the TS array from the rest of the list. Abundant examples of comparisons of that kind can be found on the Internet using query like "disk array performance comparison"

You own performance test. You can compare MS and TS disk arrays performance on your own if you have an access to both systems. Say, vendor cannot take a responsibility for the array choice but can provide you with an access to the assortment available, so you can make a comparison. There are a number of free and paid benchmark tools, which allow you to get the job done. Here is an example of two DBMS server disk arrays comparison using MS SQLIO tool. Choosing the disk array you also need to keep in mind its fault tolerance, which is achieved usually by means of redundancy (and higher price per one Kb stored). RAM size RAM size calculation procedure significantly differs depending on the model system type and the server role. RAM size calculation Multi-user model system Working server of 1C:Enterprise cluster Source data for the calculation is an overall size of RAM allocated by all 1C:Enterprise processes running on this MS server. You should register and summarize the RAM allocated during the peak workload hours for the following processes:

ragent

rmngr (if it’s running on the server)

rphost (there can be more then one rphost process on the same server) For the servers working under Windows you should obtain the memory usage basing on the Task Manager data (Memory column). For Linux servers you can use "pmap" command. Put the overall amount of memory allocated into B25 cell on the sheet "Multi-user MS" of the Excel file. The result (RAM size for the correspondent 1C:Enterprise working server) will be calculated in C25 cell. DBMS server 1C:Enterprise cluster processes allocate exactly as much memory as they need. Therefore we always can use this amount of RAM as a base for the calculation. In contrast, DBMS server can make do with as little memory as available now. In other words, the amount of memory allocated by DBMS server can be smaller than it is necessary to coping with current DBMS workload. Therefore, you can use amount of memory allocated by MS DBMS server only when you are sure it works without shortage of memory. To check the condition you can use Cache Hit Ratio counter, which reflects the relative number of queries getting data from cache (instead of the database itself). This counter has to be above 80%, i.e. at least 80% of all data has to be read from the cache. If you use MS SQL Server you can obtain the counter value by Performance Monitor (SQL Server:Buffer Manager \ Buffer Cache Hit Ratio). All DBMS working with 1C provide the counter in one form or another. Please, refer to the documentation on the DBMS you use. If Cache Hit Ratio of MS DBMS server is greater of equal to 80%, summarize memory allocated by all DBMS processes and put the sum into B26 cell of "Multi-user MS" sheet of the Excel file. The result (RAM size for TS DBMS server) will be calculated in C26 cell. If Cache Hit Ratio of MS DBMS server is than 80%, DBMS works under memory pressure, which impairs overall system performance. In this case you can use the counter "Target Server Memory" available in some DBMS. For instance, you can get it for MS SQL Server using Performance Monitor (SQL Server:Memory Manager \ Target Server Memory). Please, refer to the documentation on the DBMS you use. Put "Target Server Memory" value into B26 cell of "Multi-user MS" sheet of the Excel file. The result (RAM size for TS DBMS server) will be calculated in C26 cell. If your DBMS doesn’t support this counter you should calculate the RAM size for DBMS server basing on the RAM size for 1C server. Allocate 4 times more RAM for DBMS against overall RAM size on all 1C working servers. Please note, that you get only rough estimate using this method. Single-user test system There is no way to calculate RAM size without multi-user model system. If you don’t have one you should allocate 8 Gb RAM for 1C:Enterprise server and 24 Gb for DBMS server for every 100 users. This method most probably will give you an overestimate, so you are going to be on the safe side with these characteristics (but spend some extra for the performance you don’t really need). To calculate RAM size you can use the table "RAM size" of the "Single-user test MS" sheet of the Excel file. Put the number of users in B52 cell. Required RAM size will be calculated in B53 and B54 cells. Appendices %Processor Time You should collect "%Processor Time" counter for at least one hour of continuous users activity period. Do not use counter values collected over the period including intervals of untypically low workload, like lunch or nighttime. For Windows servers use "Processor [_Total] \ %Processor Time" counter of Performance Monitor. For Linux servers use an average value of the "us" column of the "vmstat" command output. The Start and the end points of the user action Calculating your hardware characteristics using single-user test MS you need to estimate an average utilisation of the hardware components during each action. To avoid underestimation you want to follow up the procedure:

• Prepare your test until it’s one click away of the action start. For instance, if you are estimating a document posting time, you need to open a form and fill up all documents fields, so the only thing left to do is "Post" button click.
• Start performance-measuring tool (for instance, Performance Monitor) and get it ready (add counters, turn collecting on)
• Execute the user action
• Pause the performance-measuring tool and save the result into a stand-alone file with a unique name.

After you execute all user actions you need to transfer the data you collected into the Excel file. Please be cautious of choosing the precise start and end points of the user action for it can significantly affect the calculations result. Say, one of the actions performance chart looks like that: Note, that the data includes not only user action but also some time before it starts and after it ends. For the calculation you need only the central part of the chart. This gives you the following values:

• Action start time - 5:04:24
• Action end time - 5:04:29
• %Processor time – 99.213%

Note that %Processor Time according to the first chart is almost twice as little (38.096%) and the period of time is considerably longer. If you use these values the results will be significantly underestimated. CPU cores calculation formula for multi-users MS tCPU = mCPU *mPT/100/mU*tU, where

• tCPU – the number of the cores of the target server
• mCPU – the number of the cores of the model server
• mPT – %Processor Time of the model server
• tU – the number of active users if the target system
• mU – the number of active users if the model system

%Processor Time of the MS (mPT) shows how much time (in percent) the entire processor (including all its cores) was busy working under the workload. Multiplying this value to the number of cores we get the nominal utilisation of one core. For instance, given mPT = 25% and mCPU = 4 we get an equivalent of 100% of utilisation for one core. In other words 25% utilisation if 4-cores processor is the same thing as 100% utilisation of 1-core processor. Dividing this by 100 we will get the nominal number of cores fully utilised under this workload. In our example the number is 1. That said, the nominal number of CPU cores used in MS is equal to mCPU *mPT/100. This workload was created by mU users of the model server. So the average workload created by one user is mCPU *mPT/100/mU. Basing on premise that MS and TS users produce the same workload we get the following formula for the nominal number of CPU cores fully utilised in the target server: mCPU *mPT/100/mU*tU. CPU cores calculation formula for single-users test MS tCPU =  where tCPUn – calculated utilization of processor for nth user action, which in turn calculated using the following formula: tCPUn = (tF - tS) * tFREQn * mPTn * mCPU * 0.24, where

• tS and tF – action start and end time respectively
• tFREQn – action frequency (overall number of the action execution by all users of TS per hour)
• mPTn – %Processor Time of the model server during the execution of the action
• mCPU – CPU cores number of model server

Excel stores date-time values as a number of days since 1.1.1900 where time is represented by the fractional part of the number. Therefore the user action duration is calculated as (tF - tS) * 86400. Average CPU utilization during this period of time is mPTn percent. In other words there were mPTn / 100 * mCPU cores fully utilized for that time. Distributing this utilization evenly for one hour we get the following: (tF - tS) * 86400 *  mPTn / 100 / 3600 * mCPU = (tF - tS) * mPTn * mCPU * tFREQn. Multiplying this to mFREQn (action frequency) we get: (tF - tS) * tFREQn * mPTn * mCPU * 0.24 Idle time of disk array (%) You should collect disk idle time counters for at least one hour of continuous users activity period. Do not use counter values collected over the period including intervals of untypically low workload, like lunch or nighttime. Important! Before you start collecting the disk utilization data you need to make sure there is no RAM shortage on the model server. Use "Memory / Available Mbytes" for Windows and "free" command for Linux. Free RAM available shouldn’t be under 500 Mb. For Windows servers you need to use "Physical Disk [_Total] \ %Idle Time". For Linux servers use an average value of the 100 - "%util " column of the " iostat – d -x " command output. Relative disk array performance calculation for multi-user MS tRDP = (100 - mDIdle) / 100 * tU / mU, where

• tRDP – relative performance of the TS disk array
• mDIdle – MS disk array %idle time
• tU – average number of active users of TS
• mU – average number of active users of MS

Disk %utilization time = 100 – disk array %idle time. Express the disk utilization as a unit fraction we get (100-mDUtil) / 100. This workload is created by tU users, therefore one user creates an average of (100-mDUtil) / 100 / mU nominal disk arrays utilization. Basing on premise that MS and TS users utilize disks to the same extent, we get the relative performance of TS disk array = (100-mDUtil) / 100 * tU / mU. Relative disk array performance calculation for single-user test MS tDU =  where tDUn – calculated utilization of the disk array during execution of nth user action, which can be calculated using the following formula: tDUn = (tF - tS) * mFREQn * mDUn * 0.24, where

• tS and tF – action start and end time respectively
• mFREQn – action frequency (overall number of the action execution by all users of TS per hour)
• mDUn – MS disk array average utilization during the execution of the action

Relative utilization of the disk array during this period of time is mDUn / 100. Distributing this utilization evenly for one hour we get the following: mDUn / 100 * (tF - tS) * 86400 / 3600 = mDUn * (tF - tS) * 0.24. Multiplying this to mFREQn (action frequency) we get: (tF - tS) * mFREQn * mDUn * 0.24 Comparing disk array performance using SQLIO Important! Before running the test you need to make sure that there is no side workload in the system, otherwise you can get distorted results. Download and install sqlio.msi. Download and decompress the archive in the same folder the sqlio was installed to. Run sqlio.bat. You need to repeat the procedure on both model and target computers. As a result of the test, which lasts for about 20 minutes, there will be 6 files created: Reads_1.txt, Reads_2.txt, Reads_3.txt, Writes_1.txt, Writes_2.txt, Writes_3.txt. Files contain results of disk array performance testing in a text format. To estimate if the target disk array meets your system performance requirements, you need to open the files with any text editor and transfer the data to  "SQLIO" sheet of the Excel file. The table is filled out with sample data taken from these files. You need to replace them with your data. You also need to fill B4 and B5 cells with relative target disk performance calculated on the previous step. Calculated columns "Comparison" will show the target and model performance characteristic ratio. If the ratio is not less than correspondent relative performance (i.e. target disk array outperforms model disk array to the necessary extent) the cell will be filled with green. If the ratio is worse than you need, the cell will be filled with red. If means, the performance of target disk array could not meet the requirements of your system.

Choosing server-side hardware for 1C:Enterprise system

Task definition and prerequisites

Planning the deployment of 1C:Enterprise system (referred to below as “Target System” or TS) we need to choose the servers powerful enough for the workload expected. At the same time we don’t want to waste money buying excessively powerful servers you don’t need at that time.

In other words, we need to choose the hardware with performance that is necessary and sufficient (or a bit more that that) for the target 1C:Enterprise system operation to meet the users requirements.

Target System

Before you start choosing the hardware you need to know all characteristics of the Target System (TS):

• Application. You have to have fully functional application to be used in Target System (TS).
• TS workload characteristics. You need to know how many users are to work with TS, what kind of actions they are to perform, what are the every action parameters (like number of lines in tabular part of a document or specific report settings) and how often the actions are to be performed.
• Other characteristics:
  • DBMS to be used (including version number and main settings)
  • Operating systems of server and client-side computers.
  • 1C client type, etc.

You can use the procedure below having limited notion of some TS characteristics but it can compromise the calculations accuracy.

Model System

The main concept of the procedure is to measure the hardware utilization on so-called model system (MS) and then linearly extrapolate it to the TS. Then you have to choose the hardware capable of handling with the workload you just calculated.

Model system is a live system identical with TS except the workload characteristics. Among other things MS has to:

• Work with the same application
• Work in the same applied solution mode (file mode, client/server mode)
• Have the same number of work servers and identical layout of system components;
• Have the same 1C:Enterprise, DBMS and OS versions

You need the MS to work on the real hardware, which characteristics are well known and will be used to calculate the characteristics of the TS hardware.

Below is the description of various types of the MS you can use.

Single User Test Model System

You can emulate the MS workload, performing user actions manually using any hardware you have on hand. You need to measure the utilization of the hardware components produced be every action and then calculate the overall utilization.

Use case: initial (rough) hardware characteristics calculation during the pre-sale stage of the project. Before the client is ready to sign the agreement, he asks you to give him an estimate of the hardware he is going to need. You want it done without allocation too many resources on it, given that the project isn’t started yet.

Pros:

• Relatively fast procedure (typically 1-3 days)
• No need for powerful and expensive hardware
• No need for real users participation

Cons:

• Relatively low accuracy of the result
• Relatively high complexity of the procedure
• Need for manual execution of a great number of routine actions

Multi-user model systems

Using the single user test system you measure the utilization of hardware components produced by every single operation and than calculate the overall utilization. Instead you can measure the utilization on multi-user system as it is.

Test system

Using Test-center application you can emulate multi-user activity without real users. This test development and preparation is a time consuming task but you can use it not only for hardware characteristics calculation but also for other purposes like:

• Analysis and fixing the performance and lock issues occurring only in concurrent (i.e. multi-user) environment
• Load testing before changing system parameters (like platform or application version, hardware upgrade etc.).

Use case: preparing the system to go live. The agreement is signed and all necessary functionality is developed. Before system goes live you need to choose an appropriate hardware and make sure that its performance meets client’s requirements.

Pros:

• Higher accuracy and simplicity of the calculation
• The test can be used for various tasks

Cons:

• Time consuming task (usually more than 1 month)
• You need to use hardware powerful enough to cope with the test workload.

Your Live System

If your system is already put into trial or working operation (i.e. there are real users working with the system on daily basis) you can use the system as a model.

Use cases:

• You system is on the trial operation stage. It works on the temporary hardware and there is limited number of users working with it. You goal is to figure out what hardware you are going to need for the system to operate under full workload.
• System is in working operation and you expect an increase of the number of users. You need to know what hardware you are going to need down the road.

Pros: Best accuracy without much effort

Cons: You need a real users participation to have the job done

Comparable live system

If your system hasn’t been deployed yet, but you have an access to somebody else’s comparable system, you can use it as a model.

Use case: You are planning 1C application deployment and you are aware of the similar system working in another company.

Pros: Quick and simple procedure

Cons:

• Calculation accuracy will depend on the MS parameters proximity to your system’s parameters
• You have to get an access to some parameters and elements of MS, which can be challenging managerial task.

Model System Type Selection

Below is the summary table giving you all options along with their assessment in terms of complexity, accuracy and so on.

	Single-user test system	Multi-user model systems
		Test system	Your live system	Somebody else’s live system
Efforts	Insignificant	Massive	Little	Little
Hardware capacity	Any	Significant	None	None
Procedure complexity	High	Low	Low	Low
Procedure accuracy	Low	Average	High	Decent
Need for real users	No	No	Yes	Yes

On the starting stages of the project (when you don’t have real users working with the system) you want to use a test (single or multi-user) system as MS. Using single-user test system you get less accurate calculation in literally no time. Using multi-user test system you spend significant amount of time but the result is much more accurate. Moreover, you can use the same multi-user test to perform many other tasks.

If you system isn’t deployed yet but you are aware there is a similar system working in other company, you can use it as MS.

If your system is already live, you want to use it as MS. That gives you the most accurate results without much time spent on calculation.

Hardware Characteristics Calculation

The basic concept is to measure hardware utilisation on the model system and linearly extrapolate it into the target system, which gives you TS hardware workload estimate. Having this done you can choose the hardware able to cope with the workload you calculated.

You should calculate the workload of particular TS server basing on the utilisation of correspondent MS server: DBMS server of TS – basing on DBMS server of MS and so on.

If your system has well-expressed workload patterns (as it happens, for instance, in HR systems) you should make the calculation for every pattern and choose the maximum. Say, calculated CPU cores number for the pattern "regular work during the month" is 4 whereas the same characteristic for the "payroll accounting" pattern is 16. In this case you should choose 16 as a final result.

Here is a list of hardware characteristics affecting the performance of the system most of all:

• CPU performance
• Disk array performance
• RAM size

The procedure described below allows you to determine these characteristics for server-side hardware of your system.

CPU

The procedure consists of the following steps:

• Calculation of the nominal number of CPU cores
• CPU model selection
• CPU number calculation

The procedure should be repeated for every server of TS.

Calculation of the nominal number of CPU cores

Using multi-user model systems

Please, use the Excel workbook – sheet "Multi-user MS", table "Nominal number of CPU cores. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values with your data specifying the following:

• Average number of active users of the model system (D3)
• Average number of active users of the target system (D4)
• Overall number of CPU cores on model server (B10-B11)
• Average percentage of elapsed time that the processor spends (C10-C11)

Nominal number of CPU cores will be calculated in D10-D11 cells. After that you need to choose the processor model and recalculate the nominal CPU cores number into CPU number.

See also: calculation formula.

Using single-user test model system

The procedure for single-user test model system consists of the following steps:

• Make a list of user actions. You need a list of key user actions along with every action frequency (number of executions per hour).
• Get "%Processor time" for every action. You need to logon into the test system as a real user (to enable access restrictions) and perform manually every action from the list. You need to register and save to a separate file a "%Processor time" counter value during each action execution.
• Calculate nominal CPU cores number, for every action and summarize the data across the list. Use the Excel workbook – sheet "Single-user test MS", table "Nominal number of CPU cores. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values with your data specifying the following:
• Name of the user action (A9, A10…)
• Start time of the user action to the seconds (B9, B10…)
• End time of the user action to the seconds (C9, C10…)
• The number of the actions performing by all system users per hour (D9, D10…)
• The overall number of CPU cores of the model server (B2)
• Average percentage of elapsed time that the processor spends (E9, E10…)

Nominal amount of the CPU cores will be calculated in F25 cell. After that you need to choose the processor model and recalculate the nominal CPU cores number into CPU number.

See also: calculation formula.

Choosing the processor model

When you choose the processor model you need to take into account not only the number of cores but also single-thread performance of a core.

Basic idea: choose the processor with equal or greater single-thread performance than the processor of the model system.

The most solid way to do the right choice is to pick the processor meeting all the requirements listed below:

• Of the same make as the MS processor
• Targeted to the same type of tasks
• Belonging to the same or more recent generation
• Having equal or greater clock frequency

If there are no options available you can pick a processor of any other type, but you need to assure it has the same or greater single-thread performance than the model system processor. You can compare single-thread performance of two different processors using vendor recommendations or independent benchmark data.

CPU number calculation

Nominal CPU cores number you have calculated is a non-integral number. You need to round it up and calculate a number of CPUs of the processor model you have selected.

Say, you have got nominal CPU number equal to 9.12 and have selected a CPU model having 4 cores. In fact your server will be powerful enough (for your purposes) if it has 10 cores overall, but there is only 4-cores CPUs so it’s impossible. The closest multiple of 4 which is greater than 10 is 12 which gives you a CPU number equal to 3. But there are no servers with odd CPU number available, so you have to choose a 4-CPU server, which gives you 16 cores instead of 10.

Another option is to deploy your system on a virtual rather than physical server. In this case you can allocate an exact number of CPU cores you need.

Disk array

The procedure consists of the following steps:

• Relative disk array performance calculation
• Disk array model selection

The procedure should be repeated for every server of TS.

Relative disk array performance calculation

Multi-user model system

Use the same Excel workbook – sheet "Multi-user MS", table "Relative performance of the disk array. Calculation". The table is filled out with sample data. You need to replace the yellow-filled cells sample values (B18-19, C18-19) with percent id idle time of the disk array.

Relative performance of the TS disk array will be calculated in C17-18.

Having this done you need to choose disk array model.

See also: calculation formula.

Single-user test system

Follow the same procedure you used for calculation of nominal CPU cores number. Note that the sample list of user actions in the table is the same as the list used for CPU cores number calculation. It means that using single-user test model system you want to run every operation once registering all necessary performance counters at the same time.

Having this done you need to choose disk array model.

See also: calculation formula.

Choosing the disk array model

TS disk array relative performance is a coefficient you need to multiply the MS disk array performance by to get the performance you need. For example, having relative TS disk array performance equal to 2.46 means that you need twice and a half more powerful array comparing to the MS. Sometimes relative performance can be less than 1 which means that MS disk array performance is excessive for you target system.

Disk array performance is a function of its input-output capacity, i.e. the amount of data it can process (read or write) per time unit. There are too much factors that might influence the result disk array performance, so we cannot offer a way to "calculate" its model. You need to use empirical data instead.

Here is the list of the possibilities you have:

Vendor recommendation. You know the model of MS disk array as well as relative performance of the array you are looking for. You can ask a vendor to choose an array according to these requirements. The request might sound like "we need an array working 3 times faster than the array such-and-such in such-and-such configuration".

Benchmark comparison charts. Some vendors, as well as independent organisations, compare the performance of different disk arrays and publish the results online. If you find you MS array in one of those comparison chart you can pick the TS array from the rest of the list. Abundant examples of comparisons of that kind can be found on the Internet using query like "disk array performance comparison"

You own performance test. You can compare MS and TS disk arrays performance on your own if you have an access to both systems. Say, vendor cannot take a responsibility for the array choice but can provide you with an access to the assortment available, so you can make a comparison. There are a number of free and paid benchmark tools, which allow you to get the job done. Here is an example of two DBMS server disk arrays comparison using MS SQLIO tool. Choosing the disk array you also need to keep in mind its fault tolerance, which is achieved usually by means of redundancy (and higher price per one Kb stored). RAM size RAM size calculation procedure significantly differs depending on the model system type and the server role. RAM size calculation Multi-user model system Working server of 1C:Enterprise cluster Source data for the calculation is an overall size of RAM allocated by all 1C:Enterprise processes running on this MS server. You should register and summarize the RAM allocated during the peak workload hours for the following processes:

ragent

rmngr (if it’s running on the server)

rphost (there can be more then one rphost process on the same server) For the servers working under Windows you should obtain the memory usage basing on the Task Manager data (Memory column). For Linux servers you can use "pmap" command. Put the overall amount of memory allocated into B25 cell on the sheet "Multi-user MS" of the Excel file. The result (RAM size for the correspondent 1C:Enterprise working server) will be calculated in C25 cell. DBMS server 1C:Enterprise cluster processes allocate exactly as much memory as they need. Therefore we always can use this amount of RAM as a base for the calculation. In contrast, DBMS server can make do with as little memory as available now. In other words, the amount of memory allocated by DBMS server can be smaller than it is necessary to coping with current DBMS workload. Therefore, you can use amount of memory allocated by MS DBMS server only when you are sure it works without shortage of memory. To check the condition you can use Cache Hit Ratio counter, which reflects the relative number of queries getting data from cache (instead of the database itself). This counter has to be above 80%, i.e. at least 80% of all data has to be read from the cache. If you use MS SQL Server you can obtain the counter value by Performance Monitor (SQL Server:Buffer Manager \ Buffer Cache Hit Ratio). All DBMS working with 1C provide the counter in one form or another. Please, refer to the documentation on the DBMS you use. If Cache Hit Ratio of MS DBMS server is greater of equal to 80%, summarize memory allocated by all DBMS processes and put the sum into B26 cell of "Multi-user MS" sheet of the Excel file. The result (RAM size for TS DBMS server) will be calculated in C26 cell. If Cache Hit Ratio of MS DBMS server is than 80%, DBMS works under memory pressure, which impairs overall system performance. In this case you can use the counter "Target Server Memory" available in some DBMS. For instance, you can get it for MS SQL Server using Performance Monitor (SQL Server:Memory Manager \ Target Server Memory). Please, refer to the documentation on the DBMS you use. Put "Target Server Memory" value into B26 cell of "Multi-user MS" sheet of the Excel file. The result (RAM size for TS DBMS server) will be calculated in C26 cell. If your DBMS doesn’t support this counter you should calculate the RAM size for DBMS server basing on the RAM size for 1C server. Allocate 4 times more RAM for DBMS against overall RAM size on all 1C working servers. Please note, that you get only rough estimate using this method. Single-user test system There is no way to calculate RAM size without multi-user model system. If you don’t have one you should allocate 8 Gb RAM for 1C:Enterprise server and 24 Gb for DBMS server for every 100 users. This method most probably will give you an overestimate, so you are going to be on the safe side with these characteristics (but spend some extra for the performance you don’t really need). To calculate RAM size you can use the table "RAM size" of the "Single-user test MS" sheet of the Excel file. Put the number of users in B52 cell. Required RAM size will be calculated in B53 and B54 cells. Appendices %Processor Time You should collect "%Processor Time" counter for at least one hour of continuous users activity period. Do not use counter values collected over the period including intervals of untypically low workload, like lunch or nighttime. For Windows servers use "Processor [_Total] \ %Processor Time" counter of Performance Monitor. For Linux servers use an average value of the "us" column of the "vmstat" command output. The Start and the end points of the user action Calculating your hardware characteristics using single-user test MS you need to estimate an average utilisation of the hardware components during each action. To avoid underestimation you want to follow up the procedure:

• Prepare your test until it’s one click away of the action start. For instance, if you are estimating a document posting time, you need to open a form and fill up all documents fields, so the only thing left to do is "Post" button click.
• Start performance-measuring tool (for instance, Performance Monitor) and get it ready (add counters, turn collecting on)
• Execute the user action
• Pause the performance-measuring tool and save the result into a stand-alone file with a unique name.

After you execute all user actions you need to transfer the data you collected into the Excel file. Please be cautious of choosing the precise start and end points of the user action for it can significantly affect the calculations result. Say, one of the actions performance chart looks like that: Note, that the data includes not only user action but also some time before it starts and after it ends. For the calculation you need only the central part of the chart. This gives you the following values:

• Action start time - 5:04:24
• Action end time - 5:04:29
• %Processor time – 99.213%

Note that %Processor Time according to the first chart is almost twice as little (38.096%) and the period of time is considerably longer. If you use these values the results will be significantly underestimated. CPU cores calculation formula for multi-users MS tCPU = mCPU *mPT/100/mU*tU, where

• tCPU – the number of the cores of the target server
• mCPU – the number of the cores of the model server
• mPT – %Processor Time of the model server
• tU – the number of active users if the target system
• mU – the number of active users if the model system

%Processor Time of the MS (mPT) shows how much time (in percent) the entire processor (including all its cores) was busy working under the workload. Multiplying this value to the number of cores we get the nominal utilisation of one core. For instance, given mPT = 25% and mCPU = 4 we get an equivalent of 100% of utilisation for one core. In other words 25% utilisation if 4-cores processor is the same thing as 100% utilisation of 1-core processor. Dividing this by 100 we will get the nominal number of cores fully utilised under this workload. In our example the number is 1. That said, the nominal number of CPU cores used in MS is equal to mCPU *mPT/100. This workload was created by mU users of the model server. So the average workload created by one user is mCPU *mPT/100/mU. Basing on premise that MS and TS users produce the same workload we get the following formula for the nominal number of CPU cores fully utilised in the target server: mCPU *mPT/100/mU*tU. CPU cores calculation formula for single-users test MS tCPU =  where tCPUn – calculated utilization of processor for nth user action, which in turn calculated using the following formula: tCPUn = (tF - tS) * tFREQn * mPTn * mCPU * 0.24, where

• tS and tF – action start and end time respectively
• tFREQn – action frequency (overall number of the action execution by all users of TS per hour)
• mPTn – %Processor Time of the model server during the execution of the action
• mCPU – CPU cores number of model server

Excel stores date-time values as a number of days since 1.1.1900 where time is represented by the fractional part of the number. Therefore the user action duration is calculated as (tF - tS) * 86400. Average CPU utilization during this period of time is mPTn percent. In other words there were mPTn / 100 * mCPU cores fully utilized for that time. Distributing this utilization evenly for one hour we get the following: (tF - tS) * 86400 *  mPTn / 100 / 3600 * mCPU = (tF - tS) * mPTn * mCPU * tFREQn. Multiplying this to mFREQn (action frequency) we get: (tF - tS) * tFREQn * mPTn * mCPU * 0.24 Idle time of disk array (%) You should collect disk idle time counters for at least one hour of continuous users activity period. Do not use counter values collected over the period including intervals of untypically low workload, like lunch or nighttime. Important! Before you start collecting the disk utilization data you need to make sure there is no RAM shortage on the model server. Use "Memory / Available Mbytes" for Windows and "free" command for Linux. Free RAM available shouldn’t be under 500 Mb. For Windows servers you need to use "Physical Disk [_Total] \ %Idle Time". For Linux servers use an average value of the 100 - "%util " column of the " iostat – d -x " command output. Relative disk array performance calculation for multi-user MS tRDP = (100 - mDIdle) / 100 * tU / mU, where

• tRDP – relative performance of the TS disk array
• mDIdle – MS disk array %idle time
• tU – average number of active users of TS
• mU – average number of active users of MS

Disk %utilization time = 100 – disk array %idle time. Express the disk utilization as a unit fraction we get (100-mDUtil) / 100. This workload is created by tU users, therefore one user creates an average of (100-mDUtil) / 100 / mU nominal disk arrays utilization. Basing on premise that MS and TS users utilize disks to the same extent, we get the relative performance of TS disk array = (100-mDUtil) / 100 * tU / mU. Relative disk array performance calculation for single-user test MS tDU =  where tDUn – calculated utilization of the disk array during execution of nth user action, which can be calculated using the following formula: tDUn = (tF - tS) * mFREQn * mDUn * 0.24, where

• tS and tF – action start and end time respectively
• mFREQn – action frequency (overall number of the action execution by all users of TS per hour)
• mDUn – MS disk array average utilization during the execution of the action

Relative utilization of the disk array during this period of time is mDUn / 100. Distributing this utilization evenly for one hour we get the following: mDUn / 100 * (tF - tS) * 86400 / 3600 = mDUn * (tF - tS) * 0.24. Multiplying this to mFREQn (action frequency) we get: (tF - tS) * mFREQn * mDUn * 0.24 Comparing disk array performance using SQLIO Important! Before running the test you need to make sure that there is no side workload in the system, otherwise you can get distorted results. Download and install sqlio.msi. Download and decompress the archive in the same folder the sqlio was installed to. Run sqlio.bat. You need to repeat the procedure on both model and target computers. As a result of the test, which lasts for about 20 minutes, there will be 6 files created: Reads_1.txt, Reads_2.txt, Reads_3.txt, Writes_1.txt, Writes_2.txt, Writes_3.txt. Files contain results of disk array performance testing in a text format. To estimate if the target disk array meets your system performance requirements, you need to open the files with any text editor and transfer the data to  "SQLIO" sheet of the Excel file. The table is filled out with sample data taken from these files. You need to replace them with your data. You also need to fill B4 and B5 cells with relative target disk performance calculated on the previous step. Calculated columns "Comparison" will show the target and model performance characteristic ratio. If the ratio is not less than correspondent relative performance (i.e. target disk array outperforms model disk array to the necessary extent) the cell will be filled with green. If the ratio is worse than you need, the cell will be filled with red. If means, the performance of target disk array could not meet the requirements of your system.

Downloads

• Choosing server-side hardware. Calculation
• Choosing server-side hardware. SQLIO
• Choosing server-side hardware. SQLIO results