We just submitted the defect listed below. Seems it's been around forever and becomes very obvious when you have more than a small number of active promotions. Especially those with nested conditions like product/category lists.
http://forum.cs-cart.com/tracker/issue-6296-performance-issue-in-fnpromotionsphp-fn-promotion-check/
16 second delay on add to cart went to less than 1 second where 155 active promotions were present.
Do note that an "available from/to" is a condition and so any "expired" promotions remain active and are evaluated for every add/view cart operation. Be sure to clean up unused or stale promotions in addition to the fix referenced in bugtracker.
If you disable the promotions does that help?
We've found the same thing to happen with shipping methods, CS Cart goes through all of them, even if you're only using one or two. We submitting a support request, but were told that's just how it works. It really bogs down the cart. Any ideas on a fix?
Jack
Disabling the promotino should prevent it from being evaluated. Active and Hidden will be evaluated and the expiration is part of the conditions.
This took several hours to nail down. And shipping is probably even more complex. Would be happy to work on your specific issue, but it's a time and materials type of job.
My dev and CS-cart looked into the ship methods issue and there really wasn't a solution. It's just the way CS cart builds the page; it evaluates all shipping methods not just the ones in use. ie if you have FedEx ground selected it makes a call for ALL FedEx methods, same with USPS, etc. Really bogs it down.
My dev and CS-cart looked into the ship methods issue and there really wasn't a solution. It's just the way CS cart builds the page; it evaluates all shipping methods not just the ones in use. ie if you have FedEx ground selected it makes a call for ALL FedEx methods, same with USPS, etc. Really bogs it down.
But thats not the right approach that you evaluate all the shipping methods even though they are not being used and have an overhead of API Calls on top of it. Imagine if some one has multiple shipping methods how much slow it will make the checkout page from performance perspective and this could lead to user not ordering the product eventually.
For realtime quotes, cs-cart uses a method that is common across shipping carriers (get rates). That is to get rates for all shipping methods that are available for the weight/size of the items from each configured carrier. Then from that result, they extract the carrier method that maps to the site shipping methods to determine the rates.
Long ago we did a delivery time addon and what we found that there wasn't even consistency within a carrrier's API to extract the rate info properly. I.e. you would request from a "deliver time" API and it would return a list of methods but then those methods had no correlation to the "rates api" so you couldn't even get a quote for a delivery method returned from the same carrier (but a different api).
So they choose to do a "get rates" which is all rates regardless of what's configured because most carriers don't provide you a way to get a rate for a single (or set of) method. And the methods aren't common between carriers either.
But this is way off topic so suggest you open a new thread for shipping or reopen one of the hundreds where these discussions have already occurred.