Performance issue with serials related doctypes

ERPNext
1

We have encounter a performance issue with ERPNEXT while submitting a large Purchase Receipt. Approximately, it takes more than ten minutes to submit a purchase receipt that contains 4K serials. Simultaneously, no one can access the system while submitting.

Furthermore, the same problem occurs in all the doc-types where serial is there like (Sales Invoice, Purchase Receipt, Stock Entry, etc…). Additionally, we encounter the same problem with some data-intensive doctypes and reports such as the Landed Cost Voucher doctype and Gross Profit report.

Our server specifications (DigitalOcean):
MEMORY:8 GB
VCPUS: 4 vCPUs
SSD DISK: 160 GB
TRANSFER: 5 TB

At the beginning, we didn’t encounter such a delay and performance issues. Its increasing proportionally with the data size.

I don’t know if the problem from our server or the system design?

We were happy to using ERPNEXT, but now we are afraid of this dilemma and such behaviour.

2

Hi and welcome to ERPNext

Thanks for the feedback, some questions:

What version?
V10 (or V11?) had/has seen refactoring to cache and reduce database calls.

Please explain what you mean by ‘serial’ - 4K serials of what?

“Its increasing proportionally with the data size.”

To best illustrate the context of your concerns, what do you refer to here - for example large record counts?

thanks

3

I’m now on version 10, but I’ve try version 11 on the local server and its still the same.

I mean when for example the purchase receipt has 4 thousands pieces without serial, I didn’t encounter any problem. The problem occurs when I have 4 thousands pieces with serial number.

I want to reduce the latency in submitting and to make the system available while submitting a large transaction.

4

Thanks, another question:

So then originally, to submit a PR with 4K serial items, the response in the ‘early’ days was ok? But now transactions that size take much longer?

That suggests the performance issue is on the database, possibly for eg indexing.

Otherwise if the problem is on the ERPNext side, one idea is to spawn a separate thread to handle that.

To profile a transaction would identify where the bottleneck occurs, whether on the database or ERPNext instance process.

5

Check this for ideas Number of worker running & long queue