Many merchants have reported issues regarding their StoreFront 5.0 based site over the year regarding speed. These issues usually fall into two areas:
- Slow initial page load
- Final checkout hangs and may timeout
Slow initial page load
This is due to the database clean-up routines contained in the session_onstart event. Speak English you say. This means the 1st time a customer views a page with a .asp extension all the routines to clean out abandoned carts and erase credit card numbers is run. On mature sites this can take awhile. The standard implementation is absurd to begin with because there is no need to run this routine every time a visitor hits your site. I have a replacement global.asa available which not only reduces the frequency of the clean-up routines from running, I rewrote the routines themselves so that they are an order of magnitude more efficient. This works on both Access and SQL Server based sites and the results are immediate and dramatic. Below is the result of just the change out of the standard global.asa with my own:
The key to understanding these results is the far right of the immediate results image where the response time has been averaging 15-30 seconds and immediately drops to under 0.5 seconds.
In many cases this change alone brings the site performance back to acceptable levels all the way through checkout. However, on the more mature sites another problem begins to arise.
Final checkout hangs and may timeout
There have been repeated complaints since the initial release of StoreFront 5.0 about the slowness of the final checkout page load time. This was especially apparent to merchants who's product line encouraged orders of numerous items and if they had attributes too, it could be a crap shoot if the checkout could be completed at all. The last release of StoreFront 5.0, version 50.5, offered better performance, but fell short for mature sites. As part of my rewrite of StoreFront 5.0 I traced this problem down to two main areas:
- Poor design - the order is loaded no less than six (6) times for the SE version; the AE version will add at least two additional loads PER PRODUCT in the cart, once for tiered pricing check and one for inventory. You can add an additional load if you track inventory. This is structural and cannot be fixed without a major rewrite (Note: in my version I reduced this to one load, period)
- Inefficient database access - the problem above is exacerbated by this problem, namely in many cases the application loads the ENTIRE table just to add a single record. This is why many mature sites with even a moderate order count are watching their checkout process buckle and in some cases collapse. 50.5 fixed some of this but not all. The solution is to replace the existing functions' offending code and replace them with efficient code. This is a labor intensive process and will take an average of 1/2 a day to implement. This is independent of Access and SQL Server databases as well, however, I've never seen a site running Access get to this point as they've always been converted to SQL Server by the time they've gotten to me. Also, the level of site traffic to get to this point usually requires SQL Server because of core inadequacies in the database access code anyway.
I had one site that literally seized up on final checkout. They were running SQL Server on a dedicated server and even at midnight with no traffic an order could not be completed. Nobody had been paying attention as the checkout process got slower and slower and all of a sudden their inbox filled with complaints about not being able to checkout. I spent a good portion of October patching sites with this issue in preparation for the Christmas rush.
What should I do?
1. Obtain my custom global.asa. How much for this silver bullet you say? The answer is I've provided this to my regular clients at no charge and in most cases it requires only setting the database connection path. I don't offer it for download because it still contains a few lines of LaGarde's original code. If you're a new client I simply install it for you at my standard hourly custom work rate. This helps every site dramatically but as mentioned may not be enough for busier sites.
2. If you're not on SQL Server you need to convert. Yes, the monthly bill will go up but if you're losing sales that'll make up the difference and more. Unless you shift to something dramatically different like a version of StoreFront 5.0 I tweaked out (first stress test I did 4 million page views, 13,000 orders in 20 hours against an Access db), this is a requirement.
3. Ok, you're on SQL Server but still have issues on checkout. It is time fix the database access code. This can be done in a couple of hours; please contact me for a detailed estimate.
This article was last updated on Saturday, November 24, 2007 12:00:00 AM
Return to Top