This article covers:
- Magento 1 performance
- Possible ways to compromise Magento performance & how to fix
Audiences of this article:
- Magento developers who struggle with Magento performance
- Magento store owners seeking solution to improve their store speed
1. Too Many Attribute Values
Not been able to fully understand Magento EAV while putting too many attribute values in one product attribute can result in catastrophic performance failure and believe us, it’s a costly mistake!
This is what one of our eCommerce clients has learnt in a hard way – their store admin putting nearly 500 colours variations in one colour attribute, which slowed down the query of all products associated with this colour attribute – the affected product categories took forever to load even though they may only have a handful products!
After countless hours of investigation, we realised the issue resides in the number of colour attribute values – it’s seemed to us that when such attribute is used for product configuration, 500 is just too much for Magento to handle.
Once we divided them into different colour attributes based on product brands and categories, the issue went away instantly. However, the pay back was to rebuild a few thousands products since the colour attribute was used for product configuration.
So remember that if a particular product attribute is getting overly crowded with options, be sure to split this attribute by creating more attributes according to brands or categories. This may also require you to create additional attribute sets.
From our years of hands on experience, to start any Magento project in a smart way: other than listing product categories and subcategories, you should also have an attribute and attribute set plan since they are crucial for Magento performance. We can almost guarantee that, a same sized Magento stores with the same server specs can have totally different performance, all depends on how well your developer’s database knowledge is, and whether they have a solid understanding of Magento EAV model. But a sad reality is: most developers never pay attention to these things because they ignore the fundamentals, sounds familiar right?
2. CPU High Load
CPU high load can often lead us to think of DDos attack, in fact it could be a lot of other things such as: a crashed database table, problematic Cron Jobs (too many pending cron tasks and especially if you cron is set run every minute, it will drain your CPU in no time!), an existing Magento Bug (i.e prior to Magento 2.3, we experienced instant CPU high load when the cache is disabled in developer mode, weird enough? That’s life!), or a buggy Magento extension – we seen so many third party modules shipped with bugs even in a clean Magento installation, and this is really the open source world we’re living now – a place where anyone can claim to be a pro.
Check server specs and detailed CPU/Memory usage
htop
The htop command tells us how much memory and CPU your current Magento instance consume, with detailed CPU and Memory usage of each process. This is helpful for developers to track down the performance killer.
3. Server Running Out of Space
The first sign of your server running our of space is often like this: you get a call from your client saying they cannot login Magento backend but the frontend is still running. A few SSH commands to help you checking server’s free space, and lookup the sizes of each directory
Check server storage space
df
The df command tells you how much free space your server have. For a large store, we recommend to have at least 20% free space because log files, cache and sessions can build up much quicker than expected! A simple cron job can also be set up to send your alerts once the hard drive reaches certain usage percentage.
Check folder and file sizes
du -sh *
Above command tell you the exact folder/file sizes within current directly, this is a great way to figure out which part of Magento is growing rapidly, so you can track down the hidden issues in your Magento.
4. Bot Traffic
According to ZDNet, 20% of web traffic is generated by bad bots alone in 2018. If you Magento store is not optimised to fight against bot traffic, you can suffer from both poor performance and lose of sales. Bot traffic can also be one of the main factors that your Magento session files are growing out of control. Read our recommendation on how to limit bot access.
5. Log Files Build Up
Magento Log Files Builds Up
Firstly remember that many log files are actually stored in database.
In Magento Admin -> Configuration -> Advanced -> System -> Log, you can configure the life span of log files and how frequently they get cleaned. We recommend to keep it short such as 7 days. This is because log files also have a record in database and when this table gets really large it will crash and cause all sorts of issues. If you suspect of suffering this issue, here is how you can lookup database table size using MySQL query:
SELECT
table_schema 'Database',
SUM(data_length + index_length) AS 'DBSize',
SUM(TABLE_ROWS) AS DBRows,
SUM(AUTO_INCREMENT) AS DBAutoIncCount
FROM information_schema.tables
GROUP BY table_schema;
Then to manually clean log files in your Magento root directory:
php -f shell/log.php clean
In one instance, we have dropped a Magento database dump size in half just by cleaning log files!
Error Log Files Builds Up
Code errors, especially the ones that related to cron which triggers error logging to repeat in a very short time interval (usually a cron job is set to run every 1-5 min), you can imagine how rapidly your error logs could build up in just 7 days.
Apart from building up the log file which eventually kills the server storage, having PHP errors in your Magento backend is a big No No, even thought it’s not hurting performance. So be sure to check your Apache error log, MySQL error log, and Magento error logs such as system log and exception log.
In Magento 2, we compile Magento on a regular basis whenever there’re updates, customisation or integration. It’s a great tool to spot any hidden code errors.
Magento Session Files Builds Up Rapidly
If don’t limit the access of web crawlers, search bots and third-party web crawlers alike, you will eventually hit this issue where your Magento session is builds up excessively to eventually fill up your server. Take a look at this article which talks about how to stop Magento from creating sessions for bot traffic.
6. Compromised Contact Forms
Are you sending email from your own server? If so, stop it! Use third party solutions such as SendGrid or MailGum. If you Magento contact forms are compromised by hackers to send out spam emails, you’ll notice your session folder usually builds up rapidly, and there almost nothing you can do except shutting down your email server.
A hacked contact form from the client side doesn’t necessarily mean your server is hacked, but this can be costly on both performance and hosting expense. Magento’s poor engineering in form validation makes email spamming so easy and your best way out is using a third party email solution for your transaction emails. And yes, don’t forget to shut down your own email server!
7. Over Loaded Cron Job
This has happened in some of the Magento 2 version where cron schedule table grows like a snowball in database with too many pending tasks unable to be executed. If in doubt, go check your cron_schedule table regularly to ensure your Cron is running on schedule. Cron job is the heart beat of Magento store, once it’s running wild, all sorts of weird things can happen.
