- 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:
- 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.
- Action start time - 5:04:24
- Action end time - 5:04:29
- %Processor time – 99.213%
- 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
- 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
- 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
- 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
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:
- 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.
- Action start time - 5:04:24
- Action end time - 5:04:29
- %Processor time – 99.213%
- 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
- 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
- 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
- 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
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:
- 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.
- Action start time - 5:04:24
- Action end time - 5:04:29
- %Processor time – 99.213%
- 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
- 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
- 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
- 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