 |
Services | Software | Partners | Articles | Contact |
Presentation: 2.8 Million page views per day, 70 million per month, one server!The session that I proposed for DrupalCon San Francisco 2010 on 2.4 million page views per day, 60 million pages per month, one server was accepted, and I just finished giving it. Note that from the time we proposed the talk, until we actually delivered it, the site hit new records (2.8 million page views per day, 70 million page views per month). Here are the slides from the session, which I designed to be useful on their own, even for those who did not attend. And the video of the slideshow, with the sound track, is now uploaded, and you can watch it below:
|
 
Book navigationSearch
Custom Search
|
Stream not found
Not sure if its a linux bug with your flash player, but the movie doesnt play and give me the error > Stream not found
Works for me
Works for me, and I am on Linux. You are the only one who reported a problem. Must be something on your end.
Figures have increased
As I commented on the Lullabot podcast, the figures have increased over the summer. They are:
Peak daily numbers:
3.42 million page views per day
839.9K visits per day
Monthly figures:
92.4 million page views per month.
22.8 million visits per month.
Most days are above 3 million page views, and the lowest traffic day over the last 30 days is 2.7 million.
Still on the single server that I presented back in April, and doing well.
Video is now up on your
Video is now up on your session page now too!
Why custom module instead of CCK?
I was wondering what the performance hit is for using CCK vs. creating a custom module. Did you go with a custom module simply to help reduce the number of total modules needed, or does CCK slow down a high-traffic Drupal site that much?
Thanks,
Jason
Simplicity
The main goal was simplicity, which leads to maintainability. This means less stuff to keep up to date, less stuff to worry about when upgrading the site. Also, less code to load for each page request and less hooks firing.
It was not an "Aha! that is what is making the site slow", rather an example of how to simplify: for 3 fields for one content type, it was not worth having so many modules around.
Why do you to plan to use
Why do you to plan to use Varnish instead of nginx as frontend reverse proxy? And more important, why didn't you plan to use that at the beginning?
About the website, is its layout complex? I can read from your graphs that each page uses 100 KB in average, not much for an "entertainment" website.
Well, a small Drupal site is fast, and scalable. But a large one is totally different. Great work and thank you.
We did not plan to use
We did not plan to use Varnish from the beginning simply because it is not needed. We still do not need it at present, but we will be ready with it when it is.
For nginx (and lighttpd, ...etc.), we basically like to stay with the version that is in the repository of the distro we are using, to make upgrades simple, and minimal. The nginx version in Ubuntu 8.04 LTS is old. Perhaps 10.04 will have a better version. So we don't compile things from source unless there is no other way. Simplicity is the key here.
The layout is based on Marinelli, with one column on the right hand side, and a main content column. No panels or anything like that. The front page size is around 200K.
Good stuff, thanks. So all
Good stuff, thanks. So all MYISAM tables except the three you listed which are INNODB? (users, sessions, votingapi_vote)
Selective use of InnoDB
For this particular site, yes: those are the only ones that are InnoDB, all the other tables are MyISAM.
For other sites, more tables need to be InnoDB, for example, another site had the following:
comments
node
node_comment_statistics
node_counter
sessions
term_node
url_alias
users