For years, we openly shared our knowledge and R&D around Magento optimization with the community. However, some of our content (articles, research, tools, how-to and conferences) were recovered by third parties taking over our expertise. Thus, for a long time we limited our publications and public diffusions of our Magento knowledge.
For 2016, we plan to edit a new edition of the Benchmark of e-Commerce solutions, and we wish again to share our expertise with as many people as possible, allowing the whole of Magento community to optimize and develop their websites. This is why we created a list allowing to check whether a Magento website is in a healthy state or not, and which also allowed us to develop an internal tool to check all its points automatically. We will not make this tool freely available, but we will share the list with you, so that your hosting provider or system integrator could do the job manually by himself. You will thus be able to anticipate and resolve more easily the problems you could get with the platform.
Since we host 1200+ Magento sites, we came up with a checklist to survive system integrators’ and customers’ creativity. Here it is:
- Modules / extensions: overcrowded Magento setup with tons of foreign modules tend to be slowed down
- in app/code, check the three repo:
- Community: the code pool where market extensions are usually stored
- Local: the place where system integrators are supposed to put their code
- Magento: the place where Magento native features/modules are stored
- No more than 30 modules activated is a fair compromise. When possible, check the quality/performance impact of those modules
- in app/code, check the three repo:
- Obviously, you will want to check Magento’s general configuration:
- In the first place, the local.xml and enterprise.xml files. Remember, always use a structured slow backend to store your cache information or the cache will be inactive/useless. Suitable backends are for example Redis, Database, File. NEVER USE MEMCACHED AS A SLOW BACKEND
- Poll the configuration of Magento for the core_config_data and check that it is coherent
- List the stores, check the products stored and the active ones and list them per store to check if your Magento is not burdened by inactive products
- Check the cache settings. If FPC is present (EE), is it activated (for Magento 1.13+; before this version, it is useless)? Check if all Block cache are activated
- Check the files permissions. Beware! Even if told to do so by Magento’s doc, never ever put your files in 777. This is a very bad, unneeded advice.
- Database checking. Check that the tables are not:
- Fragmented (no more than 50%)
- Growing in size indefinitely
- Check especially these tables for flushing / trunking. You can empty those tables; it will have side effects on stats or other things but it will not break the site. Most of them are safe to at least archive:
- CE Log tables: log_customer; log_quote; log_summary; log_summary_type; log_url; log_url_info (polluted by bots); log_visitor (same); log_visitor_info; log_visitor_online; sendfriend_log
- EE Log tables: enterprise_staging_log; enterprise_reminder_rule_log
- Import/export tables (only used during the import/export process, never flushed): dataflow_batch_export; dataflow_batch_import
- Archive tables: Report_compared_product_index; report_event; catalogsearch_result; catalogsearch_query; report_viewed_product_index; sales_bestsellers_aggregated_daily; sales_bestsellers_aggregated_monthly; sales_bestsellers_aggregated_yearly; enterprise_logging_event enterprise_logging_event_changes
- Index tables: index_event; index_process_event
- CE Cache & session tables: core_cache_tag; core_cache; core_session
- EE session: persistent_session
Magento Cron jobs
- Check the internal and system cron jobs scheduled to run. We often think about the system one, the one triggered by Linux with the cron daemon, but Magento also keeps an internal cron job list, that can grow large, be in error or kick in all at the same moment.
- Check the Magento settings for logs. Are they flushed? How long are they kept? How many days saved? etc.
- Detect errors in var/report, var/log/errors and var/log/exception, since applicative crashes have a rootcause that is often easy to identify in those logs. This usually leads to a 50X error code in the frontend
- Check the Apache Access and PHP Error Log to be sure they are free from 40x or 50X errors usually related to PHP crashes
- Check if the Magento debug mode is activated. It’s a performance killer.
- Check if sensitive customer data (email, credit card number, etc) are not stored in the logs of Magento, and if those logs are not in 777… Just in case. It happens more than you could imagine.
- Analyse how many SQL queries the homepage rendering is triggering. 0 is ideal (FPC & Block cache doing a good job), 40 is average; above 80, you’ll get trouble. Basically, you can activate Magento profiler, just for one IP to not overload the server, and analyse the results.
- Analyse cache health. If the backend is empty, it’s bad; if it’s overpopulated (especially in file backend), the site will be slowed down. Make the cache auto-invalidate over 24h progressively, key by key, do not flush all at once uselessly.
- Check the HTML template quality with validator.w3c.org and the CSS jigsaw.w3c.org
- Check the quality by running a Google Insight assessment of the page
- Check the .htaccess content, to see if someone has not raised the php memory limit to crazy values like 1 GB and see if Etags and Expire headers are properly configured
To put it short, this list enables to find out where some Magento issues come from. It will help you to better know your platform and to avoid, in advance, its potential bugs, slowings or issues. Typically, it is from these points that we developped our internal tool, mentioned in the introduction. They are the starting points to maintain a sane website under Magento; this list is thus a good survival guide for you, e-retailers using this technology.
We hope you will find it useful !