We’re currently experiencing significant performan...
# performance
p
We’re currently experiencing significant performance issues when loading Sales Orders, but only for specific users. For some users, the same record opens in 20–30 seconds, while for others it can take up to 1.7 minutes. The issue started on Friday with a single user, and has now spread to multiple users across both the US and Canada. It’s beginning to impact our operations. Has anyone else encountered similar behavior recently or found a root cause?
j
Ask support if they've moved you over to Oracle's Autonomous Database infrastructure at some point recently. That might not be your issue, but if support says yes, I'd bet you that's the problem.
especially if you had "routine maintenance" downtime on your account recently
p
Thank you James. Unfortunately we are still experiencing the same issue this morning.
j
Okay, again, not saying it is, but yeah it's an ongoing issue (3+ weeks for us)
p
We have an update: we identified that the issue is related to the employee’s subsidiary. The problem occurs when users try to open a USA order. Setting the user’s subsidiary to USA resolves the issue for now. Since we have both Canada and USA subsidiaries, this change appears to reduce the number of transactions the server needs to process. This is still a hypothesis, but it’s working so far. The only concern is that these users are based in Canada and may need to work with Canadian orders in the future. However, since most of their work is within the USA subsidiary, this workaround should be acceptable for now.
g
We have a number of clients with very material performance issues that point to contention at the transaction level. Meaning bulk operations on Item Fulfillments can impede Sales Order creation - taking down an restlet completely in one client (timeout). In another case certain users were impacted in in taxengine scripts. Adding their department into the employee record solved it. This latter issue points to some index issue (assuming there are dimension indexes in there somewhere). JThese issues are so expensive for clients: we are having to re-orchestrate script processes to avoid contention and baby site operations to ensure continuity of business.