A client currently has a website with a large subscription base of over 10,000 users. The primary purpose of this website is to deliver content to subscribers after they are logged in. Because of the nature of the site, it is very possible that a large % of the 10,000+ users will be accessing the site around the same times. Probably not 10k concurrent users, but it is possible that 10k people will be accessing the site within say a 4 hour time period, with a majority within a 1 hour time period.
The site needs to be redone, and I am considering Drupal. I have a decent amount of experience with Drupal, but I am concerned about redoing the site only to have it implode under that type of load. Having the site inaccessible for even a few minutes of the peak hour would be bad.
I am aware of several of the caching options, but I am concerned that they will not greatly benefit me because basically all of our users will be authenticated/logged in. However, most of the content I will be delivering will not be unique per user.
Any thoughts? I would very much like to use Drupal, as I am fermiliar with it and would much rather use built in functionality than have to code my own everything, but am concerned that the vast number of includes, hooks, and queries required for every page load might force me to look into a custom built solution that simply delivers content as efficiently as possible without all the overhead of a robust solution.
If Drupal can work, what kind of server requirements am I looking at? The current site is up and operating fine, but it serves mainly static page requests.
Comments
Just curious...
Just curious. What system are you using now?
Drupal can...
... but with the right hardware. What's your hardware situation? You'll need a fairly big database server and possibly more than one web server. You may also need to do some tuning, like adding memcache. But with that many registered users I assume you're not doing this project with zero budget.
- Robert Douglass
-----
my Drupal book
current system and hardware
The system that is currently being used is not a CMS. The crux of the site is about 100 weekly reports that are generated. Currently they are being generated as static HTML files and uploaded. The site is somewhat dynamic as it has a login system and various levels of nasty include trees for presentation stuff and bits of PHP logic here and there.
Yes there is a decent budget, but if drupal is going to require setting up several load balanced servers and lots of other overhead to serve the content, that would be a mark against it in my considerations. I feel I could build a custom solution that would serve the purpose and be light weight enough to run on the one dedicated server that we currently have... however if I could avoid doing that and stick with drupal on one server, I would much rather go that route. But I do want to avoid having to deal with enterprise level sever and drupal configuring if it can be avoided.
As far as memcache, I was under the assumption that the drupal caching systems didn't offer much performance gain for logged in users. Am I wrong, or is there a way around this? Caching systems benefiting mainly anonymous users wouldn't have much use to me.
Caching
There are many types of caching in Drupal. The page cache only benefits anonymous users but the other caches benefit everybody. These include variables, menus, blocks, filters and so forth. A drupal site can be sped up by serving these caches from memory (ie memcache).
It is really hard to estimate how much iron you need for your site. It depends greatly on exactly the functionality you have available. The fewer modules you enable the more traffic (logged in or otherwise) you can handle. If you start deploying functionality along the lines of Lifetime TV or Sony BMG (each have dozens of contrib modules and thousands of lines of custom code), then you need enterprise iron.
I suggest you at least use Drupal for rapid prototyping and then do some stress testing before you deploy.
- Robert Douglass
-----
my Drupal book