[consulting] Successful large enterprise deployments of Drupal

Michael Haggerty mhaggerty at trellon.com
Tue Dec 13 19:50:03 UTC 2005


Large is kind of a subjective term. It could refer to the amount of traffic
on a site or the complexity of the applications running within. 

For instance, we did a site for the Alliance for a Better California
(http://www.betterca.com) which received over 1 million page views a month
for the period leading up to California's special election. The kinds of
issues we ran into are with persistent database connections and security, as
the site was subjected to regular DDOS attacks that needed to be addressed
at the network level. The site right now gets about 500k page views a month
and is still subject to regular attacks. We've been able to meet a servce
level agreement of 99.99% uptime most months, and that's including regular
maintainence such as upgrading Drupal.

We have another site, Ironweed Films (http://www.ironweedfilms.com) which
gets far less traffic yet represents a totally different set of issues that
qualify it as a large enterprise deployment. The site performs transaction
processing for new members which integrates with a 3rd party processing
solution, and maintaining it is a process of figuring out what features need
to be added to serve all of the use cases that are out there. Each time we
add new features, we have to go through several levels of quality assurance
that really ends with the customer telling us if we missed something.

The cost of building and deploying each site is comparable, and we have had
great success with Drupal in each. Drupal's caching mechanism in particular
makes scalability less of a concern. The major issues we run into are
educating the client about using the content management tools, monitoring
resources on the server to ensure Drupal is running optimally, and
implementing special features such as secure logins, payment processing,
etc. 

Most of the real work of supporting large enterprise installations happens
on the network and server software levels, and there are a lot of strategies
for dealing with these. The biggest thing that comes to mind is to compile
your own installations of Apache, PHP and MySQL, I've personally found
double digit performance improvements occur (using Red Hat ES3) when these
are compiled against the actual production hardware (especially with dual
processor machines). Another thing that may be useful, and that we are
considering, is offloading SSL authentication to a separate machine, Intel
sells a completely black box solution for this that eliminates the load from
Web servers.

Something I am not real hot on right now is clustering. A lot of people look
at it as the big solution for drupal scalability, but I think it's overkill
until you exceed certain thresholds. For instance, with one of our larger
sites, we hit over 1 million page views a month using a P4 dual processor
system with a minimal amount of RAM. The time taken to generate each page,
on the PHP side, is still measured in milliseconds. Even this solution may
be overkill, as we have performed some scalability tests and found we could
double or triple the load without adding any additional hardware (I am
hesistant to find out what downgrading would accomplish).

Thank you,
Michael Haggerty
Managing Partner
Trellon, LLC
http://www.trellon.com
(p) 301-577-6162
(c) 240-643-6561
(f) 413-691-9114
(aim) haggerty321 
 

> -----Original Message-----
> From: consulting-bounces at drupal.org 
> [mailto:consulting-bounces at drupal.org] On Behalf Of Dries Buytaert
> Sent: Tuesday, December 13, 2005 12:44 AM
> To: A list for Drupal consultants and Drupal service/hosting providers
> Subject: Re: [consulting] Successful large enterprise 
> deployments of Drupal 
> 
> 
> On 13 Dec 2005, at 02:29, John Sechrest wrote:
> > We have a client which we needed to provide internal 
> services to the 
> > production line and at the same time provide a view into the custom 
> > production process thru a website. We ended up using drupal as the 
> > basis for this effort.
> >
> > I suppose you want to have success stories where you are allowed to 
> > get the URL for them.
> 
> Or some additional detail that helps us understand why this 
> is a _large_ deployment, why it has been successful.  I don't 
> think your current answer was particularly helpful for 
> puregin and the others.
> 
> --
> Dries Buytaert  ::  http://www.buytaert.net/
> 
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting



More information about the consulting mailing list