Trying to measure server requirements for a given user concurrency

Hi everyone! I’m struggling to find any consistent information regarding ERPNext server requirements and how to measure the app to see if the server can handle the number of users properly.

I could only find one official information about this on the bench wiki (under OS and Hardware Specifications) but the specs seems to be way more than I see other users commenting here on the forum across the posts and years.

I’m currently using ERPNext v12 in a 1vcpu-2gb DigitalOcean droplet with 6 concurrent users and I’m not facing any noticeable slowness or something like that. I booted up a new instance with 1vcpu-1gb with 1gb swap and I’m trying to push its load by using SIEGE. I’m not sure if it’s the best approach, but I’m doing the following actions for now:

  1. Accessing login page
  2. POST the login action
  3. View the user desktop
  4. Add a payment record

I’m testing by using this flow with a concurrency of 10 and 5, while checking the server load after each siege, and here is its result:

I’m not sure if I’m doing this right, but maybe this 1vcpu-1gb would be able to handle 5 users fine?

I’m trying to figure out so I can scale it properly for 50, 200 or even 500 users without wasting money and resources. I appreciate any help!

1 Like

VPS server performance has nearly as much to do with consistent ping times as it does with hardware specs.

Every transaction in ERPnext makes many back and forth packets from the server to your browser. So in this respect, even a slightly longer ping time will result in a noticeable lag time in your browser.

Essentially you could have a super server with 32gb of memory and 4gb of swap space and 12 concurrent processors, but if your ping time sucks, your experience will be less than desirable.

VPS severs are NOT dedicated boxes for your application. They are powerful hardware servers but they are running several, or in some cases many, virtual servers on that hardware and they have sold those virtual server instances as VPS servers. This means that your experience can also be influenced by the number of other VPS servers running on the hardware with your server.

Some VPS providers are better than others about regulating their systems to make sure all VPS systems have a reasonable experience.

I have systems with 4gb RAM, 1gb swap, and 4 virtual cpu’s running 12 concurrent users including POS terminals and accounting personnel that perform wonderful. But I also have systems with 12gb ram, 3gb swap, and 10 virtual cpu’s running only 10 concurrent users that are never happy because sometimes it takes a few seconds for a transaction to complete. The difference between those two servers is their ability to get messages back ad forth to my broswer. The small hardware virtualization does it with blinding speed and likewise the experience is top notch. The larger hardware server is about 250 miles further away from me an has only mediocre turn time with data packets.

So in all, there is much more to getting your best server performance than just the virtual specs. ERPnext requires a huge amount of data packets to be exchanged even for something like a simple report, or a POS sale and this is where your ability to move packets really is more important than any minimum hardware specs.

Hope this helps.

And as always… Your mileage may vary :sunglasses:



Python is slow. Erp is all about features but not speed. Plus current code base implementation. Do not expect you can serve 1 millions concurrent users with it. In addition, erpnext is still SME rank. Use specialized software to solve specific problem.

Agree 100% with @bkm. Latency and bandwidth are Very Important for ERPs that use a web browser as a client.

Another challenge: Concurrent Users are not performing identical tasks. For example, writing a Sales Order requires many HTTP GET, and a few POST. Smallish packets, but quite a few of them. The most expensive are (I am guessing) populating the drop-down lists. So you have lots of back-and-forth HTTP activity, but not much bandwidth.

Alternately, what about users that run reports? In this case, not a lot of “back-and-forth” traffic. But the result set could be large. What if the user wants to see All Sales from March of Year 2019? That could be -many- pages of data returned.

Here’s another factor: time of day. When I worked in retail, there was a large spike in ERP activity around 4pm every day. That is because employees were performing End Of Day tasks. Balancing cash drawers, generating new invoices, closing daily journals, applying payments, etc. The system would always be slower at 4pm, compared to earlier times in the day.

Recently, I was working on firewalls. I noticed that my VPS “neighbors” (other customers using the same provider I am) were being very chatty. Broadcasting all kinds of traffic like Dropbox, Video chat, and more. My firewall is actively blocking it. But still, if my neighbors are doing a lot of video streaming, that may not be ideal for my ERP server.

Another consideration: VPS host hardware. My VPS CPU might be slower than your VPS CPU. My provider might be using Intel i5, but yours is using Intel i7. How many other VPS clients are sharing these CPUs with me? Are they operating on the same time zone as me?

In my experience, planning hardware for large systems usually feels like “guessing”. You try your best, and choose something that feels realistic. If the performance is bad, then you troubleshoot. -Why- is it bad? Can I easily duplicate the slowness? (the worst IT requests are the ones you cannot duplicate). Which part of my system is being stressed? And then you upgrade the part of your system that is stressed, and see if that fixes the problem.

We all want to make educated, accurate decisions -now-. It’s great that you’re thinking about server requirements right away! :slight_smile:

Unfortunately, the answer isn’t simple. Sometimes we have to figure things out as we go.


Thanks for the help, guys! :smiley:

My concern is to end up scaling a server far beyond what is necessary for that usage, raising the costs. But it is really like said in the replies: aiming for something that feels realistic and tweak it as we go. I’m aware that the mileage may vary but I didn’t realize that it could be that drastic :sweat_smile: Afterall, it really depends on how the users use the software.

The only people that may have tangible information would be Frappe. As one of the largest service providers (if not the largest) they could have a lot of performance metrics and data, and reports.

I use the words “could have” instead of “do have” deliberately. Frappe may not be measuring, collecting, and cataloging that kind of data. Benchmarking and performance tuning is very time consuming, and requires a ton of effort to produce meaningful, repeatable results. Unless there was a good reason to do so (and a means of funding that effort), Frappe may not have invested in a project like that.

Likewise, even if they’ve done the work, they may not be ready/willing to freely share all that information.