While I don't have any tips for you, I want to say that we have plans to improve Commerce performance, with the separation between cart and order tables in database might improve performance of both. This should happen very soon.
Cache your cart/purchase orders, update cart in cache on add/update/remove activities of basket. forgive me if you will not like the idea.
The problem with caching carts is if you are in a load balanced environment. So request one the user sees 2 items in his cart and on the next request he could potientially see another amount. The CacheManager is not reliable when it comes to invalidation as it uses the event system where events can be missed which would be a disaster on a commerce site.
To make it reliable i would probably have to replace the built in event provider with a custom made Redis pub/sub provider or use the EPiServer Azure one.
Hoping for some performance improvements in the near future :)
we are experiencing slow cart loading performance (>100+ms per cart) for carts that actually have items in them. And as we load two carts per request we are already talking 200+ms just for loading carts which is really slowing down performance when a lot of users get on the site.
I can see from the sql server profiler that ecf_Search_ShoppingCart_CustomerAndName is the culprit and the way it is loading data will just slow down even further when more carts and purchase orders are created. We are expecting around 2000-3000 purchase orders per day and of course an even larger amount of carts. We load carts with the CartHelper class.
We are on 8.1.0, in a load balanced setup so caching must work across a load balanced setup (sticky is no-go as that is not really load balancing).
Any tips or places to adjust?