October 25, 2020


Thinking Magento

Magento - Site Speed & Performance

The big question that anyone ever asks us about Magento is site speed and performance. The community edition of Magento is and extremely hungry resource hog a lot of the time and performance can suffer if subject to shared hosting, infact most hosting providers will remove a magento site from their servers and ask that it is either placed on a dedicated or virtual private server (VPS).

Being limited by a shared server means you will not be able to make changes to php settings, so this will include memory levels, time out issues and space. The improvements in site speed and performance are therefore recommended for a dedicated or VPS. At our hosting provider, xcache is used on Magento servers to help to improve the compilation of php scripts and places it into the RAM for direct access, reducing page load times. More information can be found here. On top of this the compression of the JS and CSS files is the next line of defence from poor performance. The extension from Fooman called "Fooman Speedster" is easy to install and will compile JS and CSS files that are featured in XML files (not css or js manually inputted into the template) or XML page updates and works in conjunction with the built in Magento cache. More information can be found here.

The final solution in terms of speeding up your store will be to edit the .htaccess file to enable apache html caching of files served. This does sometimes cause problems with updating catalog.xml files for the layout, but it does update to the latest version after a short period of time. However, it's well worth it, as it speeds up store speed by around 75%

The following code can be inserted into the base of your .htaccess

AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml application/x-javascript application/x-json application/x-httpd-php
AddOutputFilter DEFLATE html xml css js php
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary
php_flag zlib.output_compression on

Magento - Flushing Tables

In our previous posts we've discussed the importance of the cronjob as well as eav attributes, but now down to something that could possibly be more important than anything else so far. The magical log tables in magento, which will slowly but surely slow down your site until it crawls. Unfortunately most Magento users suffer from this exact problem on a regular basis and it is an every growing black mass of data that can quickly put your database into a ludicrous size of gigabytes. So, what can you do to prevent it? At present log cleaning on Magento versions does not do what it says on the tin, so for this you will have to utilise the cronjob that you have setup already and a custom module, which will be set to clean out your log tables on a nightly basis.

If you're wondering about the importance of the log tables and how we can so quickly erase the data from them, then your in luck. These tables store information on vistor information, like url trends and a few other bits. Unfortunately on a busy site you can see why these would quickly fill up.

The custom module:

There are a few pieces of code to help you with this solution, but most are rather dirty hacks, that don't work with the cronjob setup of Magento and are not controllable from the admin. We have a solution, which is based around a solution created by devgento and can be found at the below link.


Download Clean Log Tables - (Requires cronjob to be up and running in Magento)

Magento - The Importance of Cronjob

Now the cronjob is probably the most overlooked factor when it comes to setting up your Magento store. The cronjob is responsible for the following;

  • Sending out product email alerts
  • Updating your catalog flat catalog each evening - these are your prices rules
  • Removing expired quotes from customers baskets
  • Updating your currencies
  • Sending out newsletters
  • Updating your google sitemap

The cronjob can also be utilised in future addons such as auto cancelling orders, cleaning out tables and expiring RMA's.

The wiki on how to setup the cronjob can be found below and it really depends on your server configuration and if you are able to set it up. Cpanel and plesk environments make this a very easy job, however both can be resource hog platforms when it comes to dealing with a Magento store.


So don't forget to get your developer or host to setup your cronjob for you. It will make the difference between a store that is becoming a black hole of expired quotes and a smooth running store.

If you have had your Magento store up and running for several years now and you've just got a cronjob to setup and running, however your receiving lots of php max_execution errors, it means your tables have become far too chunky for the cronjob to deal with. This leaves you with the quesiton of what the heck do i do now? Well, there is only one logical solution and that is the scary task of truncating tables. The main tables that you'll need to truncate are the sales_quote tables and the product alert tables. MAKE A BACKUP OF YOUR DATABASE FIRST! If you are not comfortable with this, do not attempt it and contact a Magento Developer or your hosting company to do so.

Next post - > how to prevent your database from turning into a black hole of data that you really really don't need and have it nicely cleaned each evening.

Magento - Getting To Grips

When you first come into contact with Magento, its one of those love hate relationships that makes you want to tear your own hair out 40% of the time, but has such rewards in what it can do that you'll stick by it through thick and thin.

In terms of development its always a learning curve as to how get the information you want and how it is going to be displayed. The fantastic thing about Magento is its EAV attributes (the Entity Attribute), which are the back bone and gateway to all the information in the database and allow you to avoid doing raw queries. Raw queries were a big thing in early version of Magento and this can be seen in a lot of the old modules created, such as the Softicket. Now we first started working in Magento in 2008 on version 1.6 and as time has gone on, the EAV attributes has played an important role in every upgrade. Luckily we were not subject to any major problems such as corrupting databases, but we have learnt our lessons about working on a live site. NEVER EVER DO IT. Luckily our hosting company Global Gold is also prepared to learn with us and have made the appropriate changes to their servers whenever required for the upgrades, especially when it comes to Magento performance, but we're straying off the point here.

The Magento team finally found their feet with the EAV database tables when they introduced the flat_catalog_product tables and flat_catalog_categories tables, which in essense takes the data it requires from the EAV tables and puts them into the flat_catalog tables to avoid a slowing down the database. It does cause some issues with duplicating data, but at the end of the day its performance you want after all.

If you begin to experience problems with your catalog then its normally the case that the flat_catalog tables are not updating. An example would be the tiered price rules showing or the products not being sortable on the product frontend. Things to think about... did I setup a cronjob to run refresh layered indices or is there a problem with the server running out of memory. A quick solution is to go to system cache and hit refresh layered indices. If you receive an out of memory error, then you'll need to either update the php.ini file max_memory or extend the execution time. If it refreshes correctly, then it means your cronjob is not setup to run every 5 minutes, which will in turn refresh your catalog indices each morning keeping your catalog fresh and up to date.

EAV and the flat_catalo is the future, but there is always room for improvement and we are always on the look out to how the Magento team is going to improve on this.

Page 9 of 9