The Speed Matters
There are three known methods to make Drupal running fast: hide the slow backend behind a fast frontend, distribute the load across many fast backends, or remove all slow parts and dependencies. Let’s look at some interesting details below.
Acquia.comGetPantheon.comOmega8.cc
AHide the slow backend. When you have a slow backend, like standard LAMP stack, with Apache as the main web server, you have to put it behind some fast frontend proxy cache – typically Varnish plus maybe Nginx as a load balancer. You can make PHP backend processing faster by adding APC opcode caching. You can also make the site faster for logged in users by adding Memcached – it will lower the load on the database server. This method has been used in the first incarnation of GetPantheon.com service and is currently used in the Acquia.com hosting. Since Acquia.com doesn’t add any extra technology layers on top of the Amazon cloud backend, the resulting performance is determined by Amazon EC2+S3 cloud technology and hardware own performance. The service is available in both USA and Ireland locations.
PDistribute the load. Even if you have fast backend, like modern LEMP stack, with Nginx and PHP-FPM as a web server, with APC enabled, but you want to make it scalable beyond boundaries of the single machine and local filesystem, you still have to put it behind some fast frontend proxy cache – typically Varnish. But you also need some extra magic in the backend, like distributed filesystem and virtualized resources units. This highly advanced and complex method is used in the current incarnation of GetPantheon.com service. To make it fast also for logged in users GetPantheon.com supports Redis, but it is not enabled by default. While highly sophisticated, this method still depends on the underlying cloud technology and hardware, in this case provided by Rackspace Cloud, and is available in only one USA based location, so far.
8Remove slow parts and dependencies. All of them. This method is a radical opposite to both methods listed above and is used by Omega8.cc. It is based on a modern LEMP stack, with Nginx and PHP-FPM as a web server, Zend OPcache (better and faster than APC), MariaDB and always enabled Redis to make it fast also for logged in users. However, there is no extra frontend proxy cache, because the same Nginx server acts also as a proxy cache for the PHP-FPM part of the stack. Furthermore, there is local only, high performance Hybrid SSD+SAS filesystem used and resources virtualized on the Linux kernel level directly. This solution is based on a high-end, server-class hardware, controlled in 100%, without any dependency on any other cloud stack, SAN arrays etc. While extremely fast, it allows to scale virtualized locally resources up to the size of single machine only, which is typically powered by 32-128 GB RAM and 24 CPU Threads, so it can use up to 100% of pure, dedicated machine performance. Virtualized resources units/instances can be easily moved as-is between machines if there is any need to relocate resources or to add more power to any hosted environment, but it doesn’t depend on any extra, underlying, third party technology or unknown hardware. As a result, it is not really a cloud, but a custom network built from high-end machines in seven locations worldwide.
As you can see, you can’t have everything. It is always a choice/compromise between scalability levels, redundancy (or lack of it) and performance/speed levels. If you need scalability beyond the boundaries of a single (even if very powerful) machine, you will pay the price in the complexity currency, which automatically adds more possible points of failure. If you need an unbelievable speed, you will have to pay in another currency – a lack of High Availability and infinite scalability, unless you are ready to pay a much higher price (in dollars) for some custom cluster built on a high-end hardware.
However, you shouldn’t worry too much, because most probably you don’t really need everything. Instead, identify the critical needs and preferences of your site/service and use them as a checklist in your own comparison.
!We post new articles daily (Monday-Friday), so you may want to subscribe to this feed
in your favourite RSS reader to follow up and post your comments on Twitter or App.net.
The Holy Grail of Scalability « Previous | Next » The Pricing – does it have to be complex?