Hi Everyone,
There are many questions from partners on what Resource Level of the Licensing to recommend based on specific customer patterns.
What we have on the plate is: S, M, L, XL sizes, which determine number of CPU cores at IIS server. Let me discuss the Subscription on Premise or Perpetual licensing schemes with on-premise deployment. Other words, your IIS server is sitting right in front of you and you have chance to modify it and you are not sharing it with anyone else.
End user concerns for Acumatica licensing come from certain factors:
We should transform it to more user friendly “named users concept” to identify average transactional payload.
We can help here by identifying the users as Heavy, Medium and Light. Let the end customer to tell us how many of each users they have in the organisation. Well the "user" could mean a person, or it can also be a machine entering the data, or device like POS system. I will touch data import specifically later, considering it as Super heavy User :)
Lets categorise the User types by the amount of time they spend with Acumatica ERP:
Heavy Users: 200 Operations per day 1,500 Transactions for data entry per day.
Medium Users: 50 Operations per day500 Transactions for data entry per day.
Light Users: 10 Operations per day5 Transactions for data entry per day.
By "operations" I mean accessing the screen or report , also by logins etc.
Next we should determine the time when users are actually working per day. Practically we can say that most of the data entries are done during 2 major time frames: 2 hours at any time before lunch and 1 hours after lunch.
Meaning we can reduce working day for particular Acumatica usage for 3 hours per day only (3*3600=10,800 sec). Meaning that all the transactions that user does per day will have to be made within 3 hours interval, therefore creating more load to the CPU. It is very conservative.
In fact there could be times (end of month, internal audit etc.) when number of transactions significantly increases within just single hour. But I would like to skip those peak loads for now.
We can use standard guidance for total number of transactions plus operations per CPU per hour in this case, assuming there are 3 hours in a day.
Another scenario could be the users sitting in multiple offices, working with the ERP at different time zones, anyway, good enough approximation would be active usage of ERP is 3 hours out of 8 working hours per day (well lets make our system to be stressed a bit).
To calculate how many CPU cores for IIS server is required, just calculate the result of the
(H.U.*1700 + M.U.*550 + L.U.*15)/10,800=Ops Per Second
H.U – heavy users, M.U. – medium users and L.U. – light users.
Based on result you can roughly estimate the number of CPU cores required.
Ops Per SecondRecommended Number Of CPU Cores
Less than 52
5 to 104
10 to 20 8
20+ 16
Guidance is based on average, not peak consumption, we should also reserve CPUs for data import processes if any, see below the guidance for Data Import.
It is always recommended to add 1-2 extra CPU cores to the calculated number for the sake of stability during peak loads.
Therefore it is recommended to add 1 CPU core to the total number of licensed calculated CPU cores in case of FA or SO module is in use.
![]()
As you may see, Single thread execution for the core have increased from 1,238 to 1,758 or just 40% for the last 3 years.
Let me explain what Single Thread Rating actually is - it is the speed measurement of the single core of the CPU. Other words - it determines HOW FAST your Acumatica will chew the data entered. And the thing is - Clock Speed of CPU it something that DIRECTLY affects that Single Thread Rating. It is something like REVs at your car tachometer, so more you press - faster you go uphill. Well, take note, car Gear 1 is equivalent to CPU Turbo Mode, car Gear 5 is similar to "Super Power Saving (or whatever Intel marketing dept says)" mode :). Other ratings are not that important.
The only real advantage we are getting here is 4 cores versus 10 cores per CPU chip.
But, technically, I could have placed more of older CPU chips into a single hardware box to get similar results with new CPU chip, so 10 cores vs. 4 cores is rather “questionable” advance.
For me it signifies that CPU manufacturing technology actually reached the peak in terms of single CPU core speed and we can use “standard CPU” term when recommending hardware requirements.
The choice of CPU for particular hardware configuration does not affect system speed for more than 20-40 %, so paying extra multiple times $$$ for 30% increase in CPU speed…up to you.
Finally. It makes much easier for the end customer to choose the CPU model for their server.
The only critical is CPU Clock speed, in our case it is 2.8/3.6 GHz for normal/turbo modes respectively and desired number of cores, that is only limited by our licensing terms.
It means that every line (not the order) we import in the system will occupy the single CPU core for 0.1 second. If we use more than single Import process it will occupy another CPU core, and if number of processes is bigger than number of licensed CPU cores, IIS server will start parallel execution for imports, that will effectively mean that time for single line will get doubled/tripled etc.
Let say we do import of 100,000 order lines into our system and we split these imports according to the table below, see column 2. Say for line 2 we split 50/50, for line 3 we split 33/33/33, line 4 we split by25/25/25/25 the total number of lines into multiple import processes.
![]()
What is significant here is the single import always takes single CPU core, does not matter how many licensed CPUs you have purchased. And single CPU core always gives 0.1sec per line performance.
But multiple CPU cores provide advantage if we split the import process into multiple.
Please also note, when you assume other users will use the system at the same time when you do the import, please do not run more Imports that total number of all CPUs less one, to allocate at least one CPU for the end users for data entry.
Please note however, that 0.1 second per order line per CPU core is the best time achieved so far. Under some production environment conditions, with complicated discount calculations the worst time seen yet was 0.5 sec per line per CPU core. You will need to adjust the figures from the table accordingly.
Hard drive on IIS server is not engaged most of the times, therefore you can place any type of it and any reasonable size as well.
As SQL server is very memory hungry application, that tends to place all the data into RAM for faster indexing and calculations, it is recommended to put there as much RAM as possible.
Secondary consideration is hard drives. It is recommended to use SSD drives, SSD Arrays or SAN Arrays to keep your data Input Output operations as fast as possible.
As per CPU, SQL parallelism optimization inside SQL server itself is good enough for dual core server, you can still put more CPU cores on it, based on hardware servers availability, it will not however significantly affect the server performance. There are more optimizations that can be done on SQL server but this is out of scope for the current topic.
All the best,
Sergey.
There are many questions from partners on what Resource Level of the Licensing to recommend based on specific customer patterns.
What we have on the plate is: S, M, L, XL sizes, which determine number of CPU cores at IIS server. Let me discuss the Subscription on Premise or Perpetual licensing schemes with on-premise deployment. Other words, your IIS server is sitting right in front of you and you have chance to modify it and you are not sharing it with anyone else.
End user concerns for Acumatica licensing come from certain factors:
- Number of transactions and operations per second – it directly affects CPU utilization
- Modules in use – can affect system performance as SO/FA modules take more CPU time for business logic and initial screen loads
- Usage of Import/Export functionality – Import directly affects CPU usage and should be planned ahead, very critical item for capacity planning
- Number of account/subaccounts – affects most of reports execution time as well as integrity checks and processes
- Number of Fixed Assets, other entities if they become more than 10,000 (Inventory ID, Vendors, Customers, Employees etc.) – affects system performance on processing screens, initial openings and reports
Guidance for Named Users
The main problem is that customer does not always have information about transactional/operational usage.We should transform it to more user friendly “named users concept” to identify average transactional payload.
We can help here by identifying the users as Heavy, Medium and Light. Let the end customer to tell us how many of each users they have in the organisation. Well the "user" could mean a person, or it can also be a machine entering the data, or device like POS system. I will touch data import specifically later, considering it as Super heavy User :)
Lets categorise the User types by the amount of time they spend with Acumatica ERP:
Heavy Users: 200 Operations per day 1,500 Transactions for data entry per day.
Medium Users: 50 Operations per day500 Transactions for data entry per day.
Light Users: 10 Operations per day5 Transactions for data entry per day.
By "operations" I mean accessing the screen or report , also by logins etc.
Next we should determine the time when users are actually working per day. Practically we can say that most of the data entries are done during 2 major time frames: 2 hours at any time before lunch and 1 hours after lunch.
Meaning we can reduce working day for particular Acumatica usage for 3 hours per day only (3*3600=10,800 sec). Meaning that all the transactions that user does per day will have to be made within 3 hours interval, therefore creating more load to the CPU. It is very conservative.
In fact there could be times (end of month, internal audit etc.) when number of transactions significantly increases within just single hour. But I would like to skip those peak loads for now.
We can use standard guidance for total number of transactions plus operations per CPU per hour in this case, assuming there are 3 hours in a day.
Another scenario could be the users sitting in multiple offices, working with the ERP at different time zones, anyway, good enough approximation would be active usage of ERP is 3 hours out of 8 working hours per day (well lets make our system to be stressed a bit).
To calculate how many CPU cores for IIS server is required, just calculate the result of the
(H.U.*1700 + M.U.*550 + L.U.*15)/10,800=Ops Per Second
H.U – heavy users, M.U. – medium users and L.U. – light users.
Based on result you can roughly estimate the number of CPU cores required.
Ops Per SecondRecommended Number Of CPU Cores
Less than 52
5 to 104
10 to 20 8
20+ 16
Guidance is based on average, not peak consumption, we should also reserve CPUs for data import processes if any, see below the guidance for Data Import.
It is always recommended to add 1-2 extra CPU cores to the calculated number for the sake of stability during peak loads.
Guidance for modules used
Fixed Assets module require single CPU sometimes when new screen starts, same for Sales order screen and some processing inside SO module.Therefore it is recommended to add 1 CPU core to the total number of licensed calculated CPU cores in case of FA or SO module is in use.
Guidance for determining CPU brand and model
Looking at current CPU technology, let’s compare most advanced latest CPU with 3 years old same frequency CPU:
As you may see, Single thread execution for the core have increased from 1,238 to 1,758 or just 40% for the last 3 years.
Let me explain what Single Thread Rating actually is - it is the speed measurement of the single core of the CPU. Other words - it determines HOW FAST your Acumatica will chew the data entered. And the thing is - Clock Speed of CPU it something that DIRECTLY affects that Single Thread Rating. It is something like REVs at your car tachometer, so more you press - faster you go uphill. Well, take note, car Gear 1 is equivalent to CPU Turbo Mode, car Gear 5 is similar to "Super Power Saving (or whatever Intel marketing dept says)" mode :). Other ratings are not that important.
The only real advantage we are getting here is 4 cores versus 10 cores per CPU chip.
But, technically, I could have placed more of older CPU chips into a single hardware box to get similar results with new CPU chip, so 10 cores vs. 4 cores is rather “questionable” advance.
For me it signifies that CPU manufacturing technology actually reached the peak in terms of single CPU core speed and we can use “standard CPU” term when recommending hardware requirements.
The choice of CPU for particular hardware configuration does not affect system speed for more than 20-40 %, so paying extra multiple times $$$ for 30% increase in CPU speed…up to you.
Finally. It makes much easier for the end customer to choose the CPU model for their server.
The only critical is CPU Clock speed, in our case it is 2.8/3.6 GHz for normal/turbo modes respectively and desired number of cores, that is only limited by our licensing terms.
Guidance For Data Import Process
For the data imports I suggest to use standard approach, based on import to Sales Orders screen. It takes most significant time to process lines of average 0.1 sec per line per dedicated CPU core.It means that every line (not the order) we import in the system will occupy the single CPU core for 0.1 second. If we use more than single Import process it will occupy another CPU core, and if number of processes is bigger than number of licensed CPU cores, IIS server will start parallel execution for imports, that will effectively mean that time for single line will get doubled/tripled etc.
Let say we do import of 100,000 order lines into our system and we split these imports according to the table below, see column 2. Say for line 2 we split 50/50, for line 3 we split 33/33/33, line 4 we split by25/25/25/25 the total number of lines into multiple import processes.
What is significant here is the single import always takes single CPU core, does not matter how many licensed CPUs you have purchased. And single CPU core always gives 0.1sec per line performance.
But multiple CPU cores provide advantage if we split the import process into multiple.
Please also note, when you assume other users will use the system at the same time when you do the import, please do not run more Imports that total number of all CPUs less one, to allocate at least one CPU for the end users for data entry.
Please note however, that 0.1 second per order line per CPU core is the best time achieved so far. Under some production environment conditions, with complicated discount calculations the worst time seen yet was 0.5 sec per line per CPU core. You will need to adjust the figures from the table accordingly.
Large number of Entities
In case of the large number of Accounts/Subaccounts, Fixed assets or any other master items is recommended to increase the amount of RAM for the IIS (6-8GB). It is also recommended to increase the performance of the SQL server by placing more RAM and improving I/O speed.RAM/HDD Considerations for IIS Server
As Acumatica system is optimised not to use more than 4 GB or RAM per single Application Pool, we can recommend to use 4-6 GB RAM for IIS server.Hard drive on IIS server is not engaged most of the times, therefore you can place any type of it and any reasonable size as well.
CPU/RAM/HDD Considerations for SQL Server
Even though we are not restricting you the license for SQL server, I would like to mention recommendations for it.As SQL server is very memory hungry application, that tends to place all the data into RAM for faster indexing and calculations, it is recommended to put there as much RAM as possible.
Secondary consideration is hard drives. It is recommended to use SSD drives, SSD Arrays or SAN Arrays to keep your data Input Output operations as fast as possible.
As per CPU, SQL parallelism optimization inside SQL server itself is good enough for dual core server, you can still put more CPU cores on it, based on hardware servers availability, it will not however significantly affect the server performance. There are more optimizations that can be done on SQL server but this is out of scope for the current topic.
All the best,
Sergey.
