Performance report for v9+ ERPNext in high sales volume environment

ERPNext
1

So its been a while I’ve posted here, but its about time I gave some update.

Currently i have 3 stores who do between 500 to 2000+ invoices daily and there are some performance issues.

I think subconsciously i just lost steam posting issues, which is not good for the community, these updates are useful for development.

Subjects:

Overall performance:

System will generally grind very slow and buckle up in the evenings with up to 6 cashiers posting sales, on average there are about 20 to 30+ customers at every moment, sometimes it will totally halt and need to be restarted

POS:
Funny issues progressively occur, the pos script can easily display wrong totals, i.e. showing a figure above or below the expected total maybe due to an item being added or removed and the script doesn’t update, slip gets printed with unwanted item or wrong total

Stock and Inventory:

Most of the shops have to stop inventory operations by 5pm else everything may buckle up.

Observations:

The mysql gets so bottlenecked, I can see it pushing 70+% usage on each of 7 cores of a core i7 processor, new generation, ssd powered system; just on posting some incoming pos sales.

We have disabled perpetual inventory to prevent accounting updates but it only help a little for a short while.

I think the script reliance is so much, permit me to reference v6 again as until date it is almost, in fact totally problem free except that its relatively slower, but totally error free on pos transactions.

I still think some performance improvement work needs to be done and pos should be given some focus.

The issues are seemingly worse than when I reported v6, that was purely a speed issue,. But transactions were totally dependable.

We are being forced to reset the entire transactional data at the worst hit site while keeping a live image of the current system for access and reconciliation of current transactions

2

Please check performance after changing innodb_buffer_pool_size

3

I have innodb pool set very high, I dont remember how high but has been a while i did that.

4

Okay too high innodb will also hurt performance.

Check this link out :

You can check that value in your my.cnf or even by running this query in MySQL:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

Divide that value by 1024 three times to get value in GB

5

Of 25+ shops using the system, we have complaints from the 5 or so using v9+. The v6 shops are just setup-and-forget installations, we only get calls for say, people have forgotten how to do a certain thing or maybe a virtual machine error or network error, few times, new featurea or custom reports, but core functionality complaints, almost never.

6

I’ll read your post, i followed the recommendations which I remember is some fraction of system ram installed, should be between 2 and 4gb i set. I followed guidelines at the time just dont remember what the figure was, but it was properly set.

7

yes you must have heard that 80% recommendation but that is useful for those who have seperate ERPNext and Database servers.

8

I think i used around 50, 60%, probably less, im thinking I set it at 4gb and system has 12gb ram, that’s it… Will check it when i pay them a visit

1 Like
9

on Every Invoice, ERP is updating “update_current_month_sales” in Company Table. which is a real bottle neck. if you dont need graph in Company list for sales statistics, you can comment this call in sales invoice.

@Sachin_Mane did a great analysis about ERPNext performance. after reading his posts, we improved our server almost 10 times faster for Sales Invoice and purchase invoice Submission specifically.

you should read his all posts and do changes accordingly in your code.

2 Likes
10

Great, I’ll have a look. I like to see stuff about the code, cus i know the problem is on there

11

Could you share what you did? The most effective in addition to this you posted?

12

In Sales Invoice.py

at Line 145 just comment this call “update_company_current_month_sales(self.company)”

at Line 184 comment this call “update_company_current_month_sales(self.company)”
it’s the same call in case of invoice canceled.

13

In my case, we have the call as self.update_current_month_sales() in submit and cancel

it is defined as

def update_current_month_sales(self)
if frappe…:
update_company…sales()

Is it sufficient to simply comment out the self.update_current_month_sales call in the submit and cancel functions?

14

Alright just commented the calls in the submit and cancel, I’ll test to see.

Meanwhile note that the system is generally slow, for instance it can take almost a minute to present sales invoice list, most listings take a long time. But solving POS will help us

15

Check if your Modified Field in Database has indexing…it’ll resolve your listing issue.

16

ok, elaborate on this. thanks

17

No indexing, so should I add indexing?

18

yes. and you’ll feel the difference immediately

19

Ok, how will that impact submission? I understand many indexes may also slow down queries

20

it’ll not impact on submission, but doc listing will appear quickly then before