I am currently running a Magento store, along with Wordpress, and a forum software. My Wordpress and forum seem to be performing fine, but my store’s first byte time is slow (7.2s!!!) and received an F when testing. I am attempting to do all I can to decrease this and improve my site speed.
I am currently running on a VPS server and have Apache, NGINX, and APC installed. I have tried Apachebooster which did not work with with my forum software, and I also tried Memcached, which seemed to significantly slow down the site.
I was looking into enabling FastCGI, I am using DSO right now, but it looks like it may take significant configuration to work with APC. I also have KeepAlives disabled, my host said it is always recommended to have KeepAlives disabled when running NGINX. Is this true? I am completely new to a VPS and the whole server thing, and all of this is a lot to take in.
First off, you need memory, lots and lots of memory. Make sure you’ve fed plenty to your database so that it’s able to respond to most of your queries from memory. Once sated, the amount of cpu required is surprisingly small.
As you’re already running nginx, install php in php-fpm mode, and throw apache away completely. APC runs far, far better across php-fpm than it does with apache modules ( eAcellerator seems to be king over there ), and I find the resultant chain ( nginx → php-fpm → mysql ) far simpler to understand and tune. Once this is up and running, you’ll need to start tuning up php resources ( high timeouts for admin services, plenty of mem again - 384 - 512MB per process ).
This will speed stuff up appreciably. If anything APC as an opcode cacher will make the most change.
From there, you need to look at your caching strategy. Using APC as the FE cacher is probably the fastest option, but it can get unreliable at heavy loads. I prefer to use the extended disk based cacher written by Colin Mollenheur - good to see someone really take the time to understand a file system when designing it - and put it on a memory-backed ( tmpfs ) file system. If you’re looking at multiple back ends, then Colin’s Redis based cacher is loads better than memcache.
At this point, you’ll have got to a stage where most of your info is coming from memory, and the final bottleneck is raw CPU power. The only response to that is to spend money!
Actually, it’s not. at the moment, nginx is just acting as a switch: hand this over to PHP for processing, deliver that file. Googles ngx_pagecache can process your web page to improve the quality of the content - from simple things like shrinking it my removing white space and comments, so more complex stuff like converting your background images to sprites, resizing images, combining files, and so on. It does start to use a significant amount of cpu power if you get carried away, but is is a good way to quickly improve the content. Not that’s Googles definition of improve, so up their rankings you go…
Wow thank you! I am completely new to this, so this will take me a little bit to understand, but I sincerely appreciate this post. You mention needing a lot of memory. What would you consider a lot of memory?
Ah, how long’s a piece of string??? It relates to the number of products ( x languages x websites ) you are selling, and the expected number of connections. I seem to find 2GB is a sort of threshold. Over that, and you can run a few small / 1 medium shops, under that none. I’ve never needed more than 32GB, with 8 on any single server… like I said I usually find I need the raw CPU power more.
Now linode offers 8 vCPU/4GB servers, I find this is a great workhorse.
I suggest you to use the “top” command to see what takes so much time.
I suspect your database to be your main problem.
That might explain your numbers : 10 seconds for the first page load because nothing is in cache, 2 seconds for the second load because most queries are still in cache.
If your cache is to small, the next time you’ll ask for your page, the queries results won’t be in cache anymore then it’ll take 10 seconds again.
It seems pretty clear that your problem comes from a small cache — it might also come from a saturated APC cache (same problem : not enough space → forced to recompile after a short while) but it’s pretty unlikely… because frankly, i doubt Magento’s scripts take that much CPU.
Anyway, even 2 seconds is pretty slow so it might also come from too small buffers in your database configuration (my.cnf, probably).
If you allocate to little RAM to you database, sometimes it’ll have to use temporary tables (=> disk i/o) instead of performing everything in RAM, which is hundreds (or thousands) times slower.
Google :
mysqltuner.pl
tuning-primer.sh
These 2 scripts will help you to find the appropriate settings for your MySQL configuration (assuming you’re using MySQL or MariaDB).
Magento is extremely poorly written, and generally always slow. The way the do DB queries is terrible, and uses a ton of PHP resources and memory. To get it within tolerable levels, it requires extensive use of things like memcache, tuning php, and absurd amounts of resources. This can cut first byte time in about half, but still terrible. You can also use a full page cache to increase your max concurrency.
I host all my sites on Pagodabox, they have an awesome setup for scaling resources, and have spent thousands of hours tuning their infrastructure. It requires the use of GIT, but is far easier to use and set up than typical hosting. They have a one click install for Magento, with all the optimizations already done, so you could look at what is done their, or search for a Magento optimization guide.
The first byte time issue is usually due to the server’s performance. If you are hosting on a VPS it will give you a better first byte time than shared server. I have experienced 0.24s first byte time on Cloudways magento hosting.
All this rubbish spouted about Magento - it’s not brilliant, but at least it uses the Zend Framework. Just because you don’t have the knowledge to tune it, doesn’t mean it’s not possible.
Just to prove my point, here’s a demo. FYI this is running on an old blade server ( E5440 with a current load average of 2 ) in a VPS running off it - 2 vCPUs, 1GB memory - so you’re talking in the region of $10/mo for an equivalent commercial VPS.
The poor disks are a bit hammered too (:
( best run Time to First Byte: 179 ms )
As with all CMSes, you use the same principles to tune it. Monitor, address bottlenecks, rinse, repeat.
EDIT: FYI Magento no longer uses APC cache.
The worst one I’ve ever come across was running on a windows server, with a default WAMP install. Now someone really should have been shot for that…
As you’re already running nginx, install php in php-fpm mode, and throw apache away completely. APC runs far, far better across php-fpm than it does with apache modules ( eAcellerator seems to be king over there ), and I find the resultant chain ( nginx → php-fpm → mysql ) far simpler to understand and tune. Once this is up and running, you’ll need to start tuning up php resources ( high timeouts for admin services, plenty of mem again - 384 - 512MB per process ).