Many of you who run a store with a large number of products and customers or after adding a few contributions, often complain about the store performance. This is due to the fact that the clean version of oscommerce is not optimized. And of course, your customers can’t wait for a page that takes 10 seconds or more to load. So this article will hopefully give you a few ideas, based on our experience and also contributions from the oscommerce community users. Here goes some tips we compiled:
1. Optimize your images
Many of you starts uploading heavy images which increases page load. A solution for this would be installing automatic thumbnail generator with cache features. This contribution will will cache the image instead of doing it “on the fly”, thus, server load reduces considerably.
2. Think twice before adding contributions
One of the advantages for the Oscommerce community is the broad range of pre-made contributions that users can install to the stores. But then store owners make the mistake of adding too many contributions because they want to add more and more functionality. Our advice is to install only the ones you need because. each contribution you install will add overhead to process the logic whether it be pure PHP code or MySQL queries (or both).
On the other hand, if you don’t use certain default features, like : banners, “requests since” footer display, who’s online, etc. then removing these features will increase performance.
3. Do you really need to install STS ?
STS (Simple Template System) is one of the most popular template systems available for osCommerce. However, this contribution increases the number of queries, specially when you have a significant number of categories on your store up to 200-300%.
4. Index your Sessions
If you store the sessions in the database consider adding a (primary) multi-column index on sesskey and expiry columns.
5. Unable Caching
If you have a large number of categories, products, and orders, then it is important to cache data. Some experts advice to create 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. Once you have the cache folder created and settings configured then turn on the cache features.
6. Compress page output
Oscommerce has the feature of page compression via GZIP. The optimal setting is compression level 1 for speed as higher levels will not result in significant reduction of page size.
7. Optimize your code and database queries
There is obviously different in every store, due to the fact that each of them installs different contributions although they are based in Oscommerce.
So first of all, you have to debug your queries. There is a very good contribution (written by Chemo) : per page query output contribution which 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. So that’s a good place to start with.
However, there are some existing code, that can be common functions in all the stores and you might want to take a look.
a. 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. So installing it will increase the page performance.
b. 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. Some recommend using X-Sell contribution instead.
Finally, some contributions that will help you optimize the store:
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 contribution replaces the stock logging code to only capture queries that take longer than “X” seconds to execute. Instead of storing every query it only stores the ones that are excessively resource intensive. Also, it stores more useful information such as query, time to execute, calling script, IP of browser, cookies enabled or not, and other nice data.
This contribution adds a real nice EXPLAIN feature to every query executed. It allows you to capture each query executed and associated MySQL EXPLAIN data. If you are serious about query optimization this tool is a must.
This contribution outputs the queries executed and page parse time on a per page basis without storing it to file system. This is handy to optimize page performance on a per page basis. I use it to identify redundant queries or as a quick tool to diagnose performance issues. You can tell at a glance if the lack of performance is due to MySQL, PHP, or other page factors.
This contribution has the ability to cache anything you can throw at it: parsed HTML, arrays, or even executable PHP code. If you find tough areas to optimize this class will solve your problems.
Do you have any other experience ? Please share 
December 23rd, 2011 
administrator 
Posted in 
