I am going to deploy one of my applications developed in CUBA Platform and would like to have some ideas on how I can estimate the required server config so that my clients get it ready before it is deployed and gone live. I had a look at some posts in this forum here and here and need some additional suggestions on how to estimate a variety of concurrent user ranges.
Here is some information on my application.
Server: Windows and Tomcat 9
Single war file size: 197.5 MB
Database: SQL Server 2019
The complexity of the screen: medium
Number of tables in the database: 1,100
Application Type: ERP (internal users mostly)
I understand from some posts in this forum that the requirements of processor capacity, memory size and server config/load balancer are depending mostly on the complexity of the screens, how many databases/server-side service is called per second by the users and the number of concurrent users while the middle-tier load is small. However, since I might have different clients having a different number of users in their respective scope (e.g 100, 500, 1000, 2000, 3000 users etc.), I want to have some ideas on how one can calculate the server resource requirement like as below:
A method to calculate memory required per user on an average for an application of such size
Memory required for the database and middle-tier
A method (lump-sum is fine) to calculate the processor power requirement.
Looking forward to having your experiences shared.
Hi,
There is no way to predict hardware requirements for a yet unused ERP system.
We can give you some estimations based on our existing ERP-like CUBA-based system. But you should be prepared that they most likely will be wrong, and your system may end up requiring twice as less or twice as much resources. You can only use them as a vague idea of how much resources a mature and optimized CUBA application can consume.
There can be following strategies for estimating requirements:
Performance testing.
Using other deployments of the same product as precedents.
Performance testing
It means that you perform testing in advance before delivering the system to the user.
For systems targeted for high workload such testing should be done not once but systematically in the development process before each new feature release.
You deploy the system to the target hardware that you want to test and apply a large test workload (hundreds of parallel users). If the system response time is acceptable, and system performance counters are OK then testing is passed.
Performance testing should be run with a test scenario that tries to accurately reproduce usage scenario of an average user (login, open some screens, create new entities, browse existing data using filters, go through a bpm scenario, check folders etc).
Performance loading of REST API can be done with JMeter or any other popular tool available on the market.
Using precedents
If your system is a product with multiple deployments than you can use one instance as precedent for other future deployments.
E.g. if deployment A is already running fine with workload of 1000 users and consumes X hardware, you may assume that another instance with 2000 users will consume X * 2 hardware.
Example estimation
Below I present an estimate for an existing ERP product developed in our company.
Note that this system is mature and well optimized, so it requires less hardware than freshly developed unoptimized one.
100 simultaneous users:
one server or VM holding both DB and app server
4 core CPU
10 GB RAM
SSD disk, RAID10
1000 simultaneous users:
cluster of several servers, consisting of: load balancers, web client instances, middleware instances, database servers, centralized file storage and monitoring server. Web client and middleware are deployed separately. Load balancer with sticky sessions is used to distribute web session between web client instances.
2 server/VMs for load balancer (2 cores, 2 GB RAM)
monitoring server (e.g. Zabbix or Grafana) (2 cores, 2 GB RAM)
10_000 simultaneous users:
cluster of several servers, consisting of: load balancers, web client instances, middleware instances, database servers, centralized file storage and monitoring server. Web client and middleware are deployed separately. Load balancer with sticky sessions is used to distribute web session between web client instances.
2 server/VMs for load balancer (4 cores, 6 GB RAM)
monitoring server (e.g. Zabbix or Grafana) (2 cores, 2 GB RAM)
Hope that helps as an idea of how big requirements can grow with the number of concurrent users. Any other CUBA system can differ in requirements. E.g. frontend UI user consumes much less RAM than user of Vaadin Web UI.
Thank you Alex for your suggestions in details, it’s helpful.
If I want to config resource between option 1 and 2 say for 500 concurrent users, I am thinking of two servers first to try. In that case what will be the suggested allocation of servers.
database and middle tier in server 1 and web client in server 2 as the Vaadin type of technology is resources hungry Which is fat got the client or
database in server 1 and app server (tomcat + single war ) in server 2 ?
Is there any rule of thumb to calculate load requirements and across database, middle tier and web?
Thank you Alex. One additional question, does size of the war file matters or it is only related to what are the user interfaces, business logics and database services the user using during the session in this regard as in case of a large application systems e.g. ERP not all user is going to use all functionalities in a session.