Drupal as a SAAS Offering (Part II)
What planning is required to launch a Drupal website?
Is planning really required to launch a Drupal based website? Planning a Drupal based website, like any other website, requires some discussion about basic expectations. Understanding not only Drupal's benefits but also the challenges that face a successful Drupal deployment can mean the difference between a smooth launch, and a long-term headache to maintain.
Questions that often come up in planning are :
- How many page views do I need to sustain at a peak?
- What is my expected site visitor activity going to look like?
- What modules do I need to have enabled, and what impact will these modules have on overall site performance?
- Will my site grow explosively or organically, and if explosively have I planned for sharding or load balancing in my strategy?
- Does my budget cover my hardware and hosting requirements?
When planning your web application, doing capacity planning is crucial. Having some idea of what your expected page views are, which translates to a server’s load due to the use of a database and extensive PHP in Drupal, is critical. One of the biggest mistakes developers make is under-assuming application use and not properly designing the expected scale.
With Drupal, by using web server sharding, you can help to spread your application load across several web servers. Using optimizers like APC or Xcache on the PHP side, and caching by way memcache can greatly speed up your application without needing to jump straight into hardware acquisition. As you grow, you can further expand your environment by use of load balancing with HAProxy or LVS for example, which are great alternatives to a hardware device.
Gauging what your users will be doing is equally as important as your page views. If most of your users will be anonymous for example, you can design your site to cache static content and greatly speed up the serving of pages. On the other hand, if your site is more catered towards registered users, you might be thinking due to the greatly increased database writes of ways to focus on sharding your database. To be fair, Drupal scales very well by default, and in most cases we’ve seen, simply moving to InnoDB for heavier write-based websites helps to remove the contention of full table locks that occur with MyISAM when you have users actively commenting on and writing blogs for your website.
Module selection also will play a big role in not only your development phase, but also in your maintenance phase and even your OS and software environment phases. For example, with customers that we service that run PHP 5.1.x, some modules require custom tweaking due to requirements that are not found by default in PHP 5.1.x. Because some customers require RHEL (Red Hat Enterprise Linux) or other commercial releases, it is sometimes not possible to custom write or deploy RPMs that are not supported directly by Red Hat or other vendors.
It is also important to have your Apache module list trimmed to just loading required modules, as this greatly reduces the Apache process memory utilization. Equally important is to trim PHP’s default module list and to tune the php.ini file so that you are giving PHP enough memory on the one hand for operations (Drupal can be heavy) while at the same time minimizing or even eliminating other PHP modules that you will not be using, again minimizing required server memory needs.
As you move into your deployment phase, questions that typically come up are planned site growth. If on the one hand your website is designed to service a niche vertical or segment, you should probably just focused on buying enough of a server platform that might just let you add memory, disk, or cpu to allow you to expand. On the other hand, if you are designing your Drupal CMS to be the landing spot for a commercial or enterprise audience, you should probably be thinking about it’s behavior (read or write intensive) and how you would stage your rollout. This can be as easy as doing an early stage that has just the barebones required (proxy for web, memcache strategy, optimizer strategy) that you grow into, or for really large deployments, looking closely at scaling not only the application and web layer, but also the database and possible sharding strategies.
Ultimately, in thinking about all of the above issues, the issue of budget comes into play. Traditionally years ago, the strategy would have been to just throw larger and larger servers at the problem and hope that the software would hold up. As most of the industry has discovered, this can be a very costly and painful solution, one that can be avoided by simply doing diligence up front in the planning stages.
In most well tuned application environments, usually there will be several stages to growth and a plan to make the most of each layer in each phase. At Colocube, we are well equipped to do this kind of pre-discovery and planning with our customer base. Based on our experiences, we have found that often times with some planning and engineering know how, we are typically able to help our customers to limit their initial hardware expenditure, while planning for growth that is both economical and tuned to meet their business needs.
