The architecture that you decide to use for your Magento site will directly impact the performance of the online store. This article discusses a few alternative ways you can put the puzzle together. There are more and you can be creative with where you place your caching (Varnish) server but consider the security implications of whatever architecture you arrive at.
Scenario 1. Simplest structure.
The simplest structure is to use a single server with your web server listening on port 80 and 443 (http and https). If you’re using NginX, you will need php-fpm running too. If your using Apache, you have the choice of mod_php or php-fpm (the simplest way to use Apache is with mod_php). The database is local to this server and listening only to local requests.
- Pros: Easy to administer and not much can go wrong.
- Cons: No dedicated caching as is recommended by Magento, performance will be less than ideal if using Apache with mod_php and the disk I/O will be hit hard by the database server causing this one server to have a higher than ideal load when under stress.
Scenario 2. Simple but with caching.
While NginX and Apache can cache, their can’t do it as well as Varnish. Here we’ll have Varnish configured to listen on port 80 (Varnish can’t deal with SSL so it can’t listen on port 443) and we’ll have either Apache (with php-fpm or mod_php) or NginX with php-fpm listening on port 443 for https and 8080 for http. Varnish will forward all requests up-stream to NginX on port 8080. Inbound requests for http will hit the Varnish server which will forward requests to NginX or Apache on port 8080. Inbound requests for https will hit NginX or Apache on port 443. The database is local to this server and listening only to local requests.
- Pros: It remains simple and we have the benefit of caching with Varnish.
- Cons: The database is still on this server causing I/O damage but it will be less than Scenario 1 because most requests will be dealt with my Varnish and will never make it back to the web server and the database.
Scenario 3. Split the servers up.
We’ll split the server into three parts. A proxy server, an application server and a database server. The first server is the proxy. We’ll put the web server on the proxy listening on ports 443 for https and 8080 for http. We’ll put Varnish on port 80 and have Varnish forward requests to the web server listening on port 8080. The proxy will do caching and SSL termination. The web server will send requests over to the second server – application server – which has a web server listening only on port 80 for http. The application server will forward database requests to the third server – the database server.
- Pros: The proxy server can be small and will take on the hard work of terminating the SSL connections and will do the caching. This server needs a fair amount of memory but not much CPU resources. The application server need not be as large as before in previous scenarios. It will be doing php work mostly. The database server will not be causing I/O issues to the detriment of the application server so performance will be optimal. You can add an additional application server to sit next to the original and configure the proxy server to distribute the load evenly between the two application server.
- Cons: The cost is higher because we have three servers. The complexity has gone up therefore the administration costs will be higher.