jka Posted July 10, 2017 Share Posted July 10, 2017 I have been noticing some delay when the ViewCart pages '?basket... renders. The main home page, product pages etc render within secs. However the whole view cart, secure checkout is a bit slow. Anything I can do? We do use different shipping options to check for rates. Is this the one slowing up the system, when its initially loading trying to get rates from everywhere? Quote Link to comment Share on other sites More sharing options...
Noodleman Posted July 10, 2017 Share Posted July 10, 2017 use firefox or chrome debugger and evaluate the network tab so you ccan review object load times, it shoudl help narrow the issue down if it's something obvious. otherwise, it's typically either the hosting provider have a moment of crap performance, or the underlying database server isn't performing well. Quote Link to comment Share on other sites More sharing options...
jka Posted July 10, 2017 Author Share Posted July 10, 2017 Just checked. The 2 lines that caught my attention was as follows ... 1. 302 GET index.php?-a=basket 4663ms 2. 200 GET index.php?-a=basket 4585ms Both point at the same IPAddress:443. Then then rest of the page rendered. When I check for shipping options/prices, the same happens again when the page reloads. Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 10, 2017 Share Posted July 10, 2017 Your conclusion is most likely correct: fetching a page that offers real or estimated shipping charges requires that CubeCart contact the respective courier website calculators. To verify - if this is an option for you - disable all shipping modules that use an external calculator (UPS, USPS, Canada Post, etc). Compare page response times. Quote Link to comment Share on other sites More sharing options...
jka Posted July 10, 2017 Author Share Posted July 10, 2017 Will do. However the first 302 GET seems to be confusing. Does CC redirect for SSL? Instead of rendering all pages and agnostic of 80 vs 443? Infant every call on or reload or post all starts with a 302. ?? The URL seems to be explicitly called or posted as https:// . Do this 302 is a bit confusing for all renderings GET or POST as the 1st line. Quote Link to comment Share on other sites More sharing options...
jka Posted July 10, 2017 Author Share Posted July 10, 2017 Hello Noodleman, I guess the conflict on the shipping options is causing the delays. (This is apart from the initial 302 for each page reload GET or POST) The modules conflicting are "Calculate UPS Shipping Charges based in Multiple Packages". (FYI, this extension is awesome for our multiple boxes) We also use Link products to specific shipping services. (This does not call the above extension). So we also enable the UPS Contract to call the Multiple Packages extension. Unless we enable the UPS Contract, the cheaper UPS options are not displayed. In a strange the combo of the above works so far. The overall rendering of 3000ms is doubled due to the initial 3000ms of "302 GET" Quote Link to comment Share on other sites More sharing options...
jka Posted July 10, 2017 Author Share Posted July 10, 2017 The "Link products to specific shipping services" Extension is throwing the initial 302 and making the page rendering a double call. i disabled it and the 302 went away. Quote Link to comment Share on other sites More sharing options...
Noodleman Posted July 11, 2017 Share Posted July 11, 2017 13 hours ago, jka said: Hello Noodleman, I guess the conflict on the shipping options is causing the delays. (This is apart from the initial 302 for each page reload GET or POST) The modules conflicting are "Calculate UPS Shipping Charges based in Multiple Packages". (FYI, this extension is awesome for our multiple boxes) We also use Link products to specific shipping services. (This does not call the above extension). So we also enable the UPS Contract to call the Multiple Packages extension. Unless we enable the UPS Contract, the cheaper UPS options are not displayed. In a strange the combo of the above works so far. The overall rendering of 3000ms is doubled due to the initial 3000ms of "302 GET" That would make sense. The module makes a call to UPS to request the shipping costs based on weight/dimensions and destination. The "box builder" goes through a bunch of steps before it can request the price from UPS. Depending on the quantity of items in the cart it may take a little longer. The main delay will be the time it takes to send the request to UPS, wait for them to calculate the price and download the reply. Make sure you are using the most recent version of the module as there were some performance improvements to combine the number of required API calls and thus speed it up. "Link products to specific shipping services" essentially includes each of the configured modules, I am not sure why it would be throwing a 302 as it doesn't make any direct requests itself. It includes the other modules, then has those do the requesting, so I suspect the root cause may be from another module which is called by the linking module. I would need to walk through it and debug to confirm Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.