Why is my store slow?
It’s not Magento. Out of the box, Magento is not *that* slow. It does require a proper hosting environment. It could be your hosting. It could be your extensions. It could be your theme. It could be how your admin options are configured. Or it could simply be how your staff is using it. The quickest and easiest way to find out is always to test your speed before installing or changing anything. Test again. Problems? Then you know where the problem lies. If however one morning you wake up and realize your checkout is slow, well that’s a bit harder to diagnose. First, make sure you didn’t turn your cache off and forget to turn it back on. Next, check your indexes, and make sure they are all up to date. Finally, if those don’t fix the problem try flushing your cache and letting it rebuild.
Are you still having problems? Your best bet now is to try turning things off and testing again. Switch back to the default theme, still slow? Not your theme. Start disabling extensions. Begin with any related to the problem area that is slow. If you turned them all off and you’re still slow, then it’s time to check your server resources. What’s using the CPU, php or MySQL? If it’s MySQL, check for long running queries and optimize as necessary. If it’s php, are there a lot of php processes? Yes, upgrade your server. You’re getting more traffic than normal; that’s a good thing. A small number of php processes but long running? Kill them and hope they don’t come back. If they do come back start looking at the times they spawn and determine what cron is scheduled or what employee is working at the time they begin.
What can I do to improve Magento performance?
The following admin configuration options should be checked:
- Indexes are up to date
- Caching is enabled
- JS/CSS combining is enabled
- Flat catalog is enabled
- Flat product is enabled
In your .htaccess file make sure gzip compression is uncommented out (it’s commented out by default).
Lastly, think about how you’re using Magento. Specifically your index settings and how you manage products. By default, indexes are set to update on save. However, if you have employees making many product edits or automated scripts running, you should change your indexes to manual and then manually update them after your done with your edits/imports.
Still having problems? Send an email to email@example.com/kb and let us know. We’re always happy to assist with debugging performance issues.
How do you find the peak concurrent users on your site?
To determine how much traffic (how many visitors) your site can handle, you would usually run a load test that simulates a particular number of users accessing your site at the same time, and then reports how fast your site serves web pages to those simulated users. Many people encounter a problem when they want to do this. Most, if not all, load testing systems want you to specify how many concurrent simulated users should be used in the load test, but most people only know how many visitors their website has per day or month. The question that comes up then is “how to convert visits per month to concurrent users?”
The first thing we need is information on website traffic and usage. A traditional method of gathering this information is through Google Analytics. Google Analytics provides a wealth of information about user and traffic statistics on your website. For this article, we will be using Google Analytics in our examples on how to determine concurrent users to your website for load testing.
One of the first things you will notice on the Google Analytics dashboard is the site usage statistics. The number of visits to your site is the first statistic listed; however, this alone will not show us the concurrent user information that we need for our load testing purposes, nor will it show us peak usage. The statistics for peak usage are necessary for determining if your current setup can handle a number of visitors to your site during periods of heavy usage and avoid losing business due to slow page load times.
Peak traffic can vary a lot between days, depending on many different circumstances. To view the number of visits per day in Google Analytics, just click the “Visits” link on the dashboard…
Consider an example where your peak was 84 hits.
If you find a single day where you have a lot of traffic, you can then proceed to find out something that is, even more, interesting – namely what the peak traffic is for any single hour that day. This is very easy to do and does not require any special reports. You simply have to click on hourly graphing.
When you have determined what number of visits per hour you want your site to be able to handle, you should test if your site can handle that level of traffic (with reasonably fast page load times). To do this, you have to run a load test. The problem then is that most, if not all, load testing systems will want you to specify how many concurrent (“simultaneous”) users you want to test your site. They don’t talk about users or visits per month, per day, or even per hour. So how do we translate those figures to concurrent users?
concurrent_users = (hourly_visits * time_on_site) / 3600
So, if you have 1,000 visits per hour, and each visitor stays on the average 3 minutes (180 seconds) on your site, that means you would have (1000 * 180) / 3600 = 50 concurrent users.
Note that you need to use “visits”, and not “unique visitors,” when calculating the number of concurrent users. A single physical person may visit a site twice during an hour, which will, of course, cause twice the load on the web server. So we want to count the number of times the site has been visited and not the number of unique persons that visit the site.
The time on site parameter is the average time a user spends on the site. Google Analytics will tell you about this. It is the “Avg. Time on Site” value, as shown on the dashboard.
To translate visits per month to concurrent users:
concurrent_users = (monthly_visits * time_on_site) / (3600 * 24 * 30)
So, you just divide by the number of seconds in a month, rather than as before the number of seconds in an hour.
To complete the formula, we need to take into account the pages per visit.
We adjust our formula accordingly:
x = time_on_site / pages_per_visit
y = (hourly_visits * time_on_site) / 3600
concurrent_users = x / y
This formula will give us a better idea of our performance testing target based on the value of y calculated above.
Now, when you know how many concurrent users you want your site to be able to handle, you can set up your load test. If for example, you calculate that your site experiences a maximum of 50 concurrent users, but you want to check that the site can handle occasional peaks of, say 50% more traffic, then you would want to verify that your site can handle up to 75 concurrent users. A reasonable load test setup might then be a ramp-up load test, which tests four different load levels, starting at 25 concurrent simulated users, ramping up to 50, 75 and finally 100 concurrent users. That test would show you what response times (page load times) users would experience in low (25 users) and high (50 users) traffic conditions. The load levels 75 and 100 simulated users would also show what happens when the site/service grows, or you see an exceptional burst of traffic due to some external event (maybe a big news blog writing an article about your site, generating a lot of extra traffic).
Can I use HHVM?
If you are on a Mojo Host Manager based server, you can! However, we provide no support for it, and HHVM is not only very unstable but very experimental, in general. Though it can help reduce indexing times. If you want to use HHVM purely for CLI execution, you can call it like you would PHP, for example, to run your indexes via HHVM, run this from your Magento root:
hhvm shell/indexer.php --reindexall