Firstly, don't blindly read any guide (whether provided by Magento or not) and try to ascertain server configuration and server specification for your own deployment.
Their tests and results are entirely specific to their test conditions and not applicable to your own store.
Every Magento store is different
Beyond that, selecting hardware for your deployment isn't something anyone here can do with the information you have provided.
You haven't provided nearly enough information for a useful response.
- How many visitors do you have per day peak
- How many visitors do you have per hour peak
- Do you offer digital downloads
- What amount of transit are you currently peaking at (in Mbps)
- What proportion of web traffic is SSL and none SSL
- How long are you prepared to keep stale items in a cache
For a reverse proxy, you need ...
- Proportional amount of RAM for your cache stores (min 4GB)
- Standard disks (disk I/O is not relevant)
- High end network card (to reduce interrupts, improve latency & throughput)
- Proportional amount of CPU cores to traffic level
- Optional. SSL hardware decryption
Our advice
Don't bother. At the moment, your deployment already has flaws
- 2 single points of failure
- Bottlenecked MySQL throughput over network
- Too few cores in web server
- Too many cores in DB server
- Over specified HDDs in web server
- Under specified HDDs in DB server
Believe it or not, Magento runs better on a single machine up until you hit the limits of vertical scaling, because the bottleneck of MySQL being on a high latency remote machine constrained over whatever you network speed is - is far higher than having it on the same system and having RAM speed throughout.
Don't get me wrong, there's certainly a tipping point where multi-purposing 1 machine creates its own contention issues; but 32 cores is a fairly small ceiling of load.
If you still press ahead
A Varnish cache for a low traffic site (anything under 200k unique visitors per day) doesn't usually need more than 2GB RAM and a 1 core CPU - with low end HDDs. But for you, it may as well just be on your web server anyway - it wouldn't draw any resources, and by putting it on a third machine - you'll now have 3 single points of failure and even more network activity bottlenecking your throughout.
Take that paper with a pinch of salt - it is a marketing exercise from Peer 1 and the majority of it is not correct.
vi /etc/fstab
tmpfs /path/to/var/cache tmpfs rw,uid=503,gid=503,size=2048M,nr_inodes=10k,mode=0755 0 0
mount /path/to/var/cache
Repeat above steps for var/session. Set size and nr_inodes as needed. Set uid and gid to user/group IDs of owner/group for these directories.
You can remove the tmpfs settings and re-create the directories if you need to undo it.
Best Answer
Most people run one or the other. Running them on the same server is a technical high jump and not for the faint of heart when it comes to SysAdmin issues.
The following is taken from a technical blog maintained at kbeezie.com:
Apache and Nginx Together
I’m not going to get into a lot of details about how to install and configure either http server from scratch. This article is primarily going to be food for thought for those who may want or need to configure nginx along side an existing apache (httpd) configuration. If you would rather ditch Apache all together, consider reading Martin Fjordvald’s Nginx Primer 2: From Apache to Nginx.
Side by Side
In some cases you may need to run both Apache (httpd) and Nginx on port 80. Such a situation can be a server running Cpanel/Whm and as such doesn’t support nginx, so you wouldn’t want to mess with the apache configuration at all.
To do this you have to make sure Apache and Nginx are bound to their own IP adddress, In the event of WHM/Cpanel based webserver, you can Release an IP to be used for Nginx in WHM. At this time I am not aware of a method of reserving an IP, and automatically forcing Apache to listen on a specific set of IPs in a control panel such as DirectAdmin or Plesk. But the link above will show you how with WHM/Cpanel.
Normally Apache will be listening on all interfaces, and such you may see a line like this in your httpd.conf file:
Port 80
or
Listen 80
Instead you’ll need to tell apache to listen on a specific IP (you can have multiple Listen lines for multiple IPs)
Listen 192.170.2.1:80
When you change Apache to listen on specific interfaces some VirtualHost may fail to load if they are listening on specific IPs themselves. The address option in only applies when the main server is listening on all interfaces (or an alias of such). If you do not have an IP Listed in your tag, then you do not need to worry bout this. Otherwise make sure to remove the addr:port from the VirtualHost tag.
Make sure to update the NameVirtualHost directive in Apache for name-based virtual hosts.
Once you have apache configured to listen on a specific set of IPs you can do the same with nginx.
server { listen 192.170.2.2:80; ... }
Now that both servers are bound to specific IPs, both can then be started up on port 80. From there you would simply point the IP of the domain to the server you wish to use. In the case of WHM/Cpanel you can either manually configure the DNS entry for the domain going to nginx in WHM, or you can use your own DNS such as with your registrar to point the domain to the specific IP. Using the latter may break your mail/ftp etc configurations if the DNS entries are not duplicated correctly.
Though normally if you are setting up Nginx side-by-side with apache, you’ll have your domain configurations separate from the rest of the system. The above paragraph only applies if the domain you are using has already been added by cpanel/whm and you wish to have it served by nginx exclusively. [Scroll down for PHP considerations]
Apache behind Nginx
If you are using a control panel based hosting such as cpanel/whm, this method is not advised. Most of the servers configuration is handled automatically in those cases, and making manual changes will likely lead to problems (plus you won’t get support from the control panel makers or your hosting provider in most cases).
Using Nginx as the primary frontend webserver can increase performance regardless if you choose to keep Apache running on the system. One of Nginx’s greatest advantage is how well it serves static content. It does so much more efficiently than Apache, and with very little cost to memory or processing. So placing Nginx in front will remove that burdern off Apache, leaving it to concentrate on dynamic request or special scenarios.
This method is also popular for those who don’t want to use PHP via fastcgi, or install a separate php-fpm process.
First thing that needs to be done is to change the interface apache listens on:
Listen 127.0.0.1:8080
Above we bind Apache to the localhost on an alternate port, since only Nginx on the same machine will be communicating with Apache.
Note: Since Nginx needs to access the same files that Apache serves, you need to make sure that Nginx is setup to run as the same user as apache, or to make sure that the Nginx’s selected user:group has permission to read the web documents. Often times the webroot is owned by nobody or www-data and Nginx likewise can be setup to run as those users
Then in Nginx listening on port 80 (either on all interfaces such as 0.0.0.0 or to specific IPs, your choice) we would need to configure Nginx to serve the same content. Take for example this virtual host in an apache configuration:
DocumentRoot "/usr/local/www/mydomain.com" ServerName mydomain.com ServerAlias www.mydomain.com CustomLog /var/log/httpd/mydomain_access.log common ErrorLog /var/log/httpd/mydomain_error.log ... In Nginx the equivalent server configuration would be:
server { root /usr/local/www/mydomain.com; server_name mydomain.com www.mydomain.com;
}
The above would serve all static content from the same location, however PHP will simply come back as PHP source. For this we need to send any PHP requests back to Apache.
server { root /usr/local/www/mydomain.com; server_name mydomain.com www.mydomain.com;
} In the case of rewriting (mod_rewrite) with apache behind nginx you can use an incredibly simple directive called try_files. Here’s the same code as above, but when changes made so that any files or folder not found by nginx gets passed to apache for processing (useful for situations like WordPress, or .htaccess based rewrites when the file or folder is not caught by Nginx)
server { root /usr/local/www/mydomain.com; server_name mydomain.com www.mydomain.com;
} With the above configuration, any file or folder that exists will be served by Nginx (the php block will catch files ending in .php), otherwise it will be passed back to apache on the backend.
In some cases you may wish for everything to be passed to Apache unless otherwise specified, in which case you would have a configuration such as this:
server { root /usr/local/www/mydomain.com; server_name mydomain.com www.mydomain.com;
} Personally I prefer to leave Nginx to handle everything, and specify exactly what needs to be passed back to Apache. But the last configuration above would more accurately allow .htaccess to function during almost-every request since almost everything gets passed back to apache. The css folder or any files found by the other location block would be served directly by nginx regardless if there’s an .htaccess file there, since only Apache processes .ht* files.
PHP Considerations If you are not familiar with Nginx, then it should be noted that Nginx does not have a PHP module like apache’s mod_php, instead you either need to build PHP with FPM (ie: php-fpm/fastcgi), or you need to pass the request to something that can handle PHP.
In the case of using Nginx with Apache you essentially have two choices:
1) Compile and Install PHP-FPM, thus running a seperate PHP process to be used by Nginx. This option is usually good if you want to keep the two webserver configurations separated from each other, that way any changes to one won’t affect the other. But of course it adds additional memory usage to the system.
2) Utilize Apache’s mod_php. This option is ideal when you will be passing data to apache as a backend. Even in a side-by-side scenario, you can utilize mod_php by proxying any php request to Apache’s IP. But in the side-by-side scenario you have to make sure that Apache is also configured to serve the same virtualhost that Nginx is requesting.
Speed-wise both methods are about the same when PHP is configured with the same set of options on both. Which option you choose depends solely on your needs. Another article that may be of interest in relations to this one would be Nginx as a Proxy to your Blog, which can be just as easily utilized on a single server (especially if you get multiple IP ranges like I do).