Setting a new server up, should I switch to nginx?
Our ECommerce site averages about 150,000 users a month and 1.5 million page views a month (Apporximate). This roughly comes to 50,000 page views a day with a peak of ~70,000 on our busiest day.
Given those numbers its about 30-50 Hits per Minute less than 1 req/sec.
Each page is media intensive. Every product page has ~4 Thumbnails (5k per) with ~4 Primary images (40k per) lets say. Theres also JQuery, some custom plug ins and the usual text as well. (Gzip compression wil be used to deliver the page).
When we move we will be utilizing Magento, which I know is a bit of a memory hog in of itself. I also hope to optimize images more where possible but given our products require some high resolution images (We use an image zoom feature) theres only so much wiggle room.
Magento also provides full page caching and Solr Search. While I am sure we will be using the caching I'm not sure yet if we need Solr.
So with the above info given, and assuming we grow 100% in the next year in terms of visits do people think on a 768 Linode that LAMP will be enough?
Should we look at throwing in eAccelerator or switching to LEMP Right off the bat?
Pro of Apache is I have experience with it and can tune it etc, but I've never had to deal with a commercial e commerce site like this before. Additionally, their growth is rapid. We've seen 10-20% gains in traffic every month…
13 Replies
Personally, I would use Nginx as a reverse proxy and static media server, and stick with the tried and true Apache config for the PHP stuff.
Heck, you could even split it out to a couple different Linodes. Run nginx by itself on a 512 with all the static assets, and PHP and your Database on a separate node (or even split it up further with your DB and web app servers on different nodes). That way you can upgrade each piece as you need to, and it will make your memory configurations much simpler.
Considering the large number of static files you'd be better off not having php load on every request (which modphp would do), so either apache with some form of fastcgi or nginx with reverse project to modphp.
Personally I'd go for nginx front end statically serving images etc, apache serving only php files using mod_php, setting the nginx expires header to max on static files, and lastly gzipping everything via nginx.
You'll easily run all that on a 512.
I think we'd stick to Nginx + PHP-FPM or just Apache + FastCGI, but not trying to tie both together.
We'll no doubt load up two Linodes with both configs and run some stress tests. When it happens (In a month or so) I'll be sure to create a thread to detail it all.
Sadly, all my exposure to Magento has been laden with stories of painful configuration, expensive 'templating' and woeful resource hogging. So I'm on the lookout for some happy stories
drupal is
if (!-e $request_filename) {
rewrite ^/(.*)$ /index.php?q=$1 last;
break;
}
I think the same one works for wordpress.
@obs:
It's normally not difficult to convert .htaccess rules to nginx format, i.e.
drupal is
if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?q=$1 last; break; }I think the same one works for wordpress. Some folks on nginx forums would not like your snippet
:) (I'm not fussed).
My point still holds on 2 fronts:
1) The .htaccess file comes with with code. The nginx rewrite does not.
2) Oftimes the code relies on being able to write it's own dynamic .htaccess files. Which your 'average Joe' (sorry Joe!) won't be able to replicate.
But you are right, that a lot of rewrites can be done quite simply in Nginx. They just have to be in the Nginx config and not loosely hanging around in the docroot.
Your site traffic is pretty low, so I'd say that your resource usage is going to be more defined by how much RAM it takes to get all the software you need running rather than by how much extra RAM you need to handle load (as I said, your load is very low).
Your page doesn't sound media intensive. You're looking at 180KB for those extra images, which is really pretty low, and if most of these are on a limited set of files, the disk cache will help with that. Also, linodes have pretty fast disks.
For gzip compression, lighttpd at least will cache gzipped content (it doesn't currently compress dynamic content, relying on php itself to do that), although I couldn't say if Apache did. Back when I was running a site with decent traffic (~9 million pageviews per month), the bandwidth savings from mod_deflate more than justified the minor bump in CPU usage, and that was on a box with far less CPU power than a linode (Linodes tend to have an overabundance of CPU power).
Stuff like JQuery is all client-side, so that doesn't affect your resource usage (asynchronous stuff is a different story).
Linodes scale almost laughably easily; resizing a linode takes very little time. I've resized two 768s into 512s, and the entire process took under half an hour. That can also be reduced to a single reboot if you're desperate to limit downtime by buying extra RAM on the current plan level. Economically, buying extra RAM doesn't make sense compared to upgrading the linode, but it does mean that you get 60 second of downtime instead of half an hour.
Because of this, I'd suggest starting with a 512. Start there, make sure you tune everything properly, and see what your memory usage is like. If you don't have enough breathing room, it's stupidly easy to upgrade your linode.
10-20% growth is awesome (good for you!), but easy to handle. If you don't mind setting aside some scheduled maintenance every few months to upgrade your linode, you should be golden.
Assuming you're going to keep growing at 10-20% for a long time to come, you should plan ahead and prepare for horizontal scaling rather than just vertical. While it's easy to upgrade your linode, disk IO does not necessarily scale linearly; at some point it might be more useful to split the load among two or more linodes.
The first step in this can be as simple as separating the database server from the application server. This is pretty trivial, as you just move the database to another linode and update the host/ip that your software connects to. From there, things can get a bit trickier, but if you're going to grow indefinitely, eventually your load will become extremely large and you should think about these things ahead.
This isn't a linode concern by any means, the question about how far to scale vertically before you scale horizontally applies to everything, even colocated servers, although in that case it's often because past a certain point the cost for performance stops scaling linearly, like when you need to move from 4GB to 8GB sticks of RAM and they suddenly cost a ton more per GB
@Guspaz:
While I still far prefer lighttpd to apache (I find lighttpd far easier to configure), I'd agree that most of the RAM savings you'd get from moving from Apache to lighttpd/nginx can be had with Apache by using mpm_worker and fastcgi.
Your site traffic is pretty low, so I'd say that your resource usage is going to be more defined by how much RAM it takes to get all the software you need running rather than by how much extra RAM you need to handle load (as I said, your load is very low).
Your page doesn't sound media intensive. You're looking at 180KB for those extra images, which is really pretty low, and if most of these are on a limited set of files, the disk cache will help with that. Also, linodes have pretty fast disks.
For gzip compression, lighttpd at least will cache gzipped content (it doesn't currently compress dynamic content, relying on php itself to do that), although I couldn't say if Apache did. Back when I was running a site with decent traffic (~9 million pageviews per month), the bandwidth savings from mod_deflate more than justified the minor bump in CPU usage, and that was on a box with far less CPU power than a linode (Linodes tend to have an overabundance of CPU power).
9 million views per month, in theory I'd be making 45x more money
I'm just curious. Do you still have two 512s? One for your database and the other for PHP?
I've got three Linodes. One under my own account as a personal Linode, and two for Otakuthon. We're only using one right now, the plan is to use the second server for groupware and other internal use.
as for the configuration
I prefer a combo of Nginx and Apache2. I just proxy whatever needing PHP to Apache2 which i personally find to be easy and very configurable. Nginx offloads Apache with serving static files. In most usecases i see an increase of about 100req/s in overall performance, and a huge decrease in memory usage.
For your stated load, I'd put the database on one 512 instance and the web frontend (apache, php and maybe varnish) on a second 512 instance.
This way you can scale your db and www independently. You also have lots of room to boost the hardware performance of each instance before you need to start introducing additional machines. Note: you'll need to do some MySQL config tuning to get the most out of it on a 512 instance.
I'm not familiar with Magento but, assuming it is an application server of some sort, you may also be able to give this its own 512 instance (if server load warranted it).
Other benefits of splitting functions across VMs: improved security, easier systems management (for software upgrades etc.) and ability to rapidly scale by adding more machines (as your code should already be setup to work in a distributed fashion).