TechExpertBlog

There’re some basic tips to optimize the performance of your OSCommerce powered store front.

IMAGES
It’s important that you have dedicated thumbnail size picture for an item instead of doing it "on the fly" as it decreases server load tremendously. Alternatively, you can use automatic thumbnail generator with cache features. The effects may not be noticeable on a store with 1 or 2 visitors per hour but if you do any kind of serious volume you will defitely want to cache the images. if you’ve spent the server resources to create the thumbnail image why not store it and use it later instead of creating it again?

CONTRIBUTIONS
Install ONLY the ones that you need to operate and ONLY the ones that will either save time or add value to the shopping experience. What contributions will fit these requirements will depend on the type of store you have and products for sale. Each contribution you install will add overhead to process the logic whether it be pure PHP code or MySQL queries (or both). As a rule of thumb, KEEP THE NUMBER OF CONTRIBUTIONS INSTALLED TO A MINIMUM. Too many times a store owner will go contribution happy and install every toy possible. This adds tremendous bloat to the code base and performance suffers. The intent was to make a better shopping experience but the net effect is to DECREASE the experience due to slow loading pages.

REMOVE FEATURES NOT USED
There are several features of stock osCommerce that stores may or may not use that would help performance if removed. For example: banners, "requests since" / counter footer display, who’s online, etc.

If you don’t use the features remove (comment out) the code.

Another benefit of eliminating those features is that it prevents a store from using the MySQL query caching features. On each insert the cache is flushed. Of course, this also means storing the sessions on the filesystem!

STS - Simple Template System
It is one of the worse offenders for queries and is also one of the more popular template systems available for osCommerce. If you have a significant number of categories on your store this contribution will kill your page performance. It performs a full table scan on each page request. If you have more than a few hundred categories it will increase your page load time by 200-300% based on server specifications.

In short, if you want speed don’t use a template system. Learn to modify the monolithic application that is osCommerce.

SESSIONS
If you store the sessions in the database consider adding a (primary) multi-column index on sesskey and expiry columns. This will take up more physical space but will be much faster and will be a const query type.

CACHING - Stock Code and Page Cache
The ability to cache data is very important to performance, especially if you have a large number of categories, products, and/or orders. It’s recommend creating a directory ABOVE the publicly accessible document root and giving it proper permissions for the server read/write. Creating it ABOVE the document root ensures that would-be hackers cannot access it with their web browser. Set your cache directory settings to this filepath to keep it from being stored in the "/tmp" folder which will cause issues.

Once you have the cache folder created and settings configured TURN ON THE CACHE FEATURES. This is especially effective with the category box!

The Page Cache contribution  was created for those stores that have so many contributions installed it would be nearly impossible to optimize the code. The correct answer is to not bloat the store with contributions that are not needed, but if you find yourself in that position then Page Cache may be for you. Use the Page Cache contribution as a last resort, not as a first line choice.

COMPRESS YOUR PAGE OUTPUT
Most are aware of page compression via GZIP. The optimal setting is compression level 1 for speed as higher levels will not result in signifant reduction of page size. However, a quick trick is to phyically compress the data being GZIP’d by removing extra whitespace and line breaks.

Here is the function can be used:

Code:
function compress_buffer ($buffer) {
 # Return the compressed buffer
 return str_replace("\n", ‘ ‘, preg_replace(’/\>\s+\</’, ‘> <’, $buffer));
}

Of course, this is offered as a starting point for you and you’ll have to figure out how to use it in combination with GZIP.

The physical page compression with GZIP compression will reduce the output HTML code by some 60-75% and will dramatically increase page performance especially on dial connections.

CODE / QUERY OPTIMIZATION
The fact is that every store is different. They all start with the same code base but each store installs different contributions which results in great variation as to which code needs to be optimized.

A good starting point would be to install a per page query output contribution. This will allow you to see which queries are being executed on a per page basis and easily identify those that are redundant or taking excessive time to execute. Once you pinoint what needs to be done it’s easier to actually do it. Never perform ANY optimization blindly. ALWAYS modify code for a purpose. Sounds like common sense? You would be surpised.

Once again, this won’t approach specific contribution optimizations but will only discuss those that are common to every osC store. One such contribution is an abstraction of the MS3 tax class for MS2. This replaces the stock MS2 tax code with the new tax class for MS3 which is much more efficient and uses less queries per page. The tax query is EXECUTED ON EACH PRICE DISPLAY EVEN IF THE SETTING TO DISPLAY TAX IS DISABLED. It’s important to know that fact since most think if they turn off the option in the admin control panel it will not query for the tax. This is false and even if the setting is turned off it will STILL RUN THE TAX QUERY. Why is this important? Because the tax query is one of the most server intensive queries for all of osCommerce! For a 2 minute install it will increase the page performance / server load tremendously.

The also_purchased module (product info pages) is a powerful upsale tool however, it is the absolutely most server intensive query for the osCommerce application. This is especially true for those stores that have a significant number of products and orders. This would bring a dual 2.8 Ghz CPU, 1GB RAM server to its knees, by just running that 1 query. As you accumulate more orders you will get a feel for which products would be ideal cross sell items and thus it would be advisable to install a X-Sell contribution. It may be a bit more work to maintain but the increase in product page performance is well worth the effort.

On each page request the contents of the configuration table are loaded as define statements. The implication of this is that on each page request the server must perform a table scan to generate the data, which depending on how many contributions you have installed will add overhead to each page load. An excellent contribution that addresses this issue is Faster Page Loads, Less DB Queries. This contribution caches the data and eliminates the database query, thereby saving the table scan for when the cache is not present. This contribution is HIGHLY recommended.

This post is not meant to be a difinitive guide to optimizing an osCommerce store but will hopefully give you a few pointers as to which areas should be addressed as a priority to your optimizination efforts.

Source: http://forums.oscommerce.com/index.php?showtopic=144736