Among the top 500 most visited sites on the Internet, myLifetime.com receives 6.5 million visitors (3.6 million unique) and 50 million page views per month. Because of online campaigns, and the popularity of associated television shows, the Lifetime family of sites must be prepared to accommodate significant volume spikes. Nathan Potter, VP of Digital Media Technology at myLifetime.com, cites show-related volume spikes of 150,000 page views per hour as within the normal range of traffic. The site has been load tested to levels of over 500,000 page views per hour directly to the Drupal servers.
Download the full case study from:http://acquia.com/resources/library/case-study-lifetime-digital

Comments
Nice writeup!
Nice writeup!
Did Acquia work on that project? I see Acquia branding all over the PDF, but it's unclear what Acquia's role was in that project.
-= Jeff Robbins | Lullabot | Drupalize.me =-
We only wrote the case study
Hi Jeff, we didn't work on the mylifetime project. We just helped write the case study, along with Lifetime Digital, to showcase the performance and scalability of Drupal.
Thanks,
Kieran
Good case study, it would be
Good case study, it would be nice to know more about the details of the server architecture. They initially started with a community version of Mysql but felt the need to move towards a replacating master <-> 2 slaves with heartbeat monitoring. That version of Mysql is the enterprise level version which costs an arm and a leg. In addition, they mention the use of memcached servers. Did they the deploy the cache router module? Or was there custom written caching references to the module. Info is interesting but not really helpful for the rest of us who are looking into using some of their architecture feats for some of our own projects.
Hi. Lifetime does use the
Hi. Lifetime does use the community version of MySQL. The heartbeat is provided by a Red Hat Cluster with the data switched on fiber channel attached storage. We actually switched off of the Enterprise version when we switched to a hosting provide that could support MySQL as well.
With regard to memcache we are not using cache router in our Drupal 5 or Drupal 6 sites. We do all our caching in Memcache so there's nothing to route.
I'm not sure what additional level of detail you're interested in (there is a lot to cover) but I've posted more on my blog.
MySQL replication and heartbeating
Hi, I don't know which exact version of MySQL they are using. However, I do know that when I set up master-master heart beat replication for CivicSpaceOnDemand we used an external heartbeat service to fail over the master MySQL server. Drupal.org does not use an enterprise license of MySQL for it's master master configuration, and I know other organizations that implement master-master with a heartbeat service that don't use an enterprise license for MySQL.
With regards to Memcache, Lifetime Digital has Drupal 5 and Drupal 6 sites. They were using Drupal with memcache prior to the cache router being publicly available to the best of my knowledge. But if I recall correctly Slantview was involved early on in that project.
We wrote this case study to validate what's possible with Drupal. We wanted to help many organizations that are evaluating Drupal, have a tangible reference for demonstrating it's possible to get both performance and scalability using Drupal. In the past, we've been able to point to Drupal.org as a large site, but for many organizations they wanted a larger, and more enterprise class reference.
If you want specific technical details, you might want to jump into #drupal-infrastructure and ask what drupal.org is using for Memcache, and better yet, offer to be a system administrator for the redesign and learn while while helping out.
Kieran
Thanks for the info Amazon.
Thanks for the info Amazon. I'm interested in what heartbeat solution you are using. I understand master-master replication is possible with the community version of Mysql but in order to have master-master with heartbeat and auto failover an enterprise version of Mysql utilizing clustering would be the next step. You mention it is possible to perform the heartbeat monitoring and auto failover with a 3rd party solution. May I ask what it is?
uCARP
Hi, for CivicSpaceOnDemand we used uCARP. We simply ran a script when uCarp realized it was the new master.
Kieran
Drupal.org MySQL - Heartbeat v2+CIB+Mon
From Drupal.org DB Admin Narayan Newton:
nnewton: Amazon: Heartbeat v2+CIB+Mon. Heartbeat does failover when it loses contact with the other node or when mon tells it to, mon hits mysql and attempts to login actually checking if the service is alive
nnewton: We use CIB because heartbeat in this case is managing 6 resources in 2 resource sets
nnewton: CIB being the "fancy" XML heartbeat configuration language, its a pain
nnewton: We use master-master active/passive with auto-increment offsets to make failover easier. Even in a master-slave setup you have a 20-30 second window when you are processing writes on both dbs, hence without some sort of auto-inc offset you have a percentage likelyhood of having a "dirty" failover
nnewton: we use offsets to avoid that
authenticated
Indeed a great case study - it would be great if we got a little more detail on the solving of the problem of load for authenticated users, but overall a very nice write up.
Dev and Support: prometsource.com
Thanks for the Study and Writeup
Very nice study, Some technical details on how others can optimize their websites, would be good as well.
Such stories inspire me and i am more confident that i can also increase speed of my website.
Thanks once again,
Dhaliwal