I recently did upgrade of a client server from v17 to v18. It contains a number of custom modules but I saw a serious downgrade in performance after the upgrade and I dont think its coming from the custom modules.
The server in on odoosh. We have 1 worker. there are about 40 tills. Each till does say 50-60 orders daily. We never had any major performance issues except maybe load times to open the session became increasingly larger because of an increase in number of products.
Cashiers started complaining about long loading times when selling (when orders are written to the server). It never finished loading (no error in console). A lot of tills were unusable. Internal users said the system was basically unusable. (accounts, procurement, hr etc)
I checked the server monitoring tool. I noticed a significant spike in http and postgresql and cpu % usage. Cpu usage went as high as 90%. The number of concurrent requests went as high as 60. There was nothing different about today aside from the upgrade I did the night before. Look at the comparison between today (08/09/2025) and the previous monday (01/09/2025) before the upgrade
08/09/2025
01/09/2025
None of the custom pos modules make any calls to the server directly to generate those number of http calls. Cron usage is low.
Looking at the logs, I see a lot of these websocket post requests. I guess they are coming from pos calls.
Is my deduction correct that this is coming from pos tills trying to send updates to each other or is there something I am not considering. I appreciate your advice. This is urgent to us. What can we do? Is increasing the number of workers the solution?
"Is increasing the number of workers the solution?": a temporarily one - maybe. You probably want to check out the Profiler first though: https://www.odoo.com/documentation/18.0/developer/reference/backend/performance.html
Thanks for the link. Looks like a very useful tool. Why "temporary" though? Do you think the issue is more with how it was programmed?
Because throwing resources at a problem, unless verified that a general lack of the same is indeed the root cause, will usually just obfuscate the actual issue and/or delay its re-occurrence. However, it could be a temporary fix to buy you some time to investigate further.
I have no way of telling whether the issue stems from a bad line of code. Its as plausible as anything else for the moment in my opinion. Therefore investigate via the profiler to try and figure where thing start to get a slow.
If possible, you could check how the systems reacts to not sharing orders with other PoS (unset "Share Open Orders" option, if active).
Order sharing isnt active. I however see a lot of websocket notifications about updates in the console. I think there is a lot of communication between all the pos devices and it increases exponentially with the number of devices.