The most widespread question concerning Magento is a question about Magento performance and Magento development. If you browse the Internet resources, you can find many different tips as to it, but you can’t be sure whether they are useful or not.
The first thing you need to understand is the more complex the system (product, site, etc.), the more demanding system to the resources (in other words, to the hardware).
The same is with the data. The more data is being processed by the system, the more demanding system to the resources. We will try to clarify a bit.
The simplest site will work with different speed depending on the number of records in the database (the more records, the slower system).
So, Magento is a very complex system with the thousands of data and it is very requiring system to the resources.
So, how to improve the performance of such a requiring system!?
- 1. You should enable all the variants of the caching: Admin → System → Cache Management. If you have Magento Enterprise Edition, please, don’t forget to enable « Full Page Caching».
- 3. If the products quantity is more than a thousand, we advise you to enable Flat Tables Admin → System → Configurations → Catalog in the section «Frontend» and allow the options «Use Flat Catalog Category» and «Use Flat Catalog Product». It will make the frontend faster, but it will add some work to the re-index option.
- 4. If your store is not in the test mode, you should disable the system log files, because it will release a big part of the resources: Admin - System - Configurations - Developer in the section «Log Settings». The option «Enabled» is responsible for it. You can make the entire catalog faster by disabling the use of Layered Navigation, but we don’t advise to do it. Even more, you should improve your Layered Navigation with the additional extension, for example, GoMage Advanced Navigation one which will help you to increase your sales.
- 5. The huge size of the database makes the work slower. So, we advise you to remove the products attributes which are not used. Sometimes, import/export can fail during the work process and in this case the temporary data is left in the tables dataflow_batch_export and dataflow_batch_import respectively. Also, the log files tables or the tables with the debug information can be crammed if you have forgotten to disable them. If you need to find what tables are the biggest ones, you should use the following SQL request:
- 1. SELECT table_name article_attachment, engine,
- 2. ROUND(data_length/1024/1024,2) total_size_mb,
- 3. ROUND(index_length/1024/1024,2) total_index_size_mb, table_rows
- 4. FROM information_schema.tables
- 5. WHERE table_schema = 'magento'
- 6. ORDER BY 3 desc limit 20;
But if you are not the fan of the log files, you can use the following request:
- 1. truncate table dataflow_batch_export;
- 2. truncate table dataflow_batch_import;
- 3. truncate log_customer;
- 4. truncate log_quote;
- 5. truncate log_summary;
- 6. truncate log_url;
- 7. truncate log_url_info;
- 8. truncate log_visitor;
- 9. truncate log_visitor_info;
- 10. truncate log_visitor_online;
It helps to release the database in the majority of the cases. If you have any customizations, we advise you to check the frontend with the enabled profiler in order to check the subject of the complex (narrow) areas, paying attention to the request quantities of these or those methods, memory consumption and so on.
- 1. Use the dedicated server;
- 2. Use the additional server for the database (one server is for the site, another one is for the database);
- 3. Don’t save the session in the file system, but use memcached;
- 4. If you often use the admin panel, there is the use to separate the backend and the frontend on the different servers;
- 5. It seems to be better to buy the necessary quantity of the servers, have your own system administrator instead of hiring the host provider.
We have highlighted only several useful moments. There is no limit to perfection. Just do it!