Slow performance when adding to cart

[seanrockster]

Hi

We seem to have issues when customers add items to the cart when the site is under load, lets say, 300-400 concurrent users. I mean a few seconds (+5) to add items to the cart. Granted its not a simple action as the prices are external so is the product info and we store additional properties for the order and for each line. On my dev machine with prices and product info cached, adding a single item still takes 500-600ms. Is that an expected range for adding items to the cart? We do get high cpu usage during peak times so that may be contributing but I'm trying to narrow down where the bottleneck may be.

Thanks.

[mattbrailsford]

It's really hard to say without knowing the custom code that is involved.

One thing I could say off the bat is that if you implement a custom ProductAdapter or anything that works with external data, it becomes your responsibility to cache this effectively. The ProductAdapter can be called quite a few times for the same item so if you end up fetching it from an external system each time it's requested, that could really slow things down.

Cleaning up old carts can also slow things down over time. We have a future task to implement some cart cleanup logic, but until then it would pay to implement a scheduled task to delete old abandoned carts.

If it is database related, might also be worth checking SQL Server to see if it suggests adding any more DB indexes.

[mattbrailsford]

Do you have a lot of discounts setup? that can be costly some times, but then again, If that was being slow, I'd expect that to be slow every time an order is recalculated 🤔

Let me know once you have some timings and I'll see if I can think where might be affecting it.

[seanrockster]

Hi @mattbrailsford

No, we do not have discounts, well, at least not in umbraco commerce, the pricing logic is exported from the client's erp and we make adjustments to products based on delivery regions and customers as its b2b. I've added some timers around almost everything i can within the method in question and its interesting, and odd. This has only started happening since upgrading umbraco to 13.5.2, which is why we though it might be something there. What I find is adding lines and saving the order is ok, no issues. Customers can save multiple lines at once (often 10, 20 or 30+) and still its all fine.

What I did discover is that we publish a notification via mediator with all of the lines added etc after the order is saved. That handler makes 2 log entries for the data. This is by request because our client's customers tend to forget what they order and then dispute the charges etc. Again, this was all working fine before the upgrade. However, I've removed that notification (it still negatively affected performance without await) and it does seem quicker. However I need to evaluate this during peak time mid-day UK time so I'll come back to this this evening or tomorrow.

[mattbrailsford]

Really interesting insights, I appreciate you coming back with these updates. Hopefully we can get to the bottom of it 👍

[seanrockster]

@mattbrailsford

Ok, I think I've cracked it. The line to publish the notification was within the using statement for the unit of work. Removing it or moving it outside the using statement seems to have solved the cpu issues. Again, its odd because it was all working nicely before the upgrade.

Thanks for your assistance.

[mattbrailsford]

Hmmm, that is odd. But if it resolves your issue, that's great.