The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.
By roresteen on
Can Drupal handle a community portal of 100,000 active users?
Thanks,
Rob
The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Can Drupal handle a community portal of 100,000 active users?
Thanks,
Rob
Comments
http://drupal.org/node/88416
http://drupal.org/node/88416 worth a read through.
Slashdot and Digg are different than a portal
Yes, it is good to know that Drupal holds up well under those conditions. Slashdot and Digg don't generally present as much as a problem as a busy portal site, though. Serving pages to logged-in users is much harder than serving to anonymous users. That is because much more information pertaining to access rights, customization, history, preferences etc. must be loaded and processed for logged in users. It is also easier to cache for anonymous users since they see the same thing. It is very hard to cache for logged in users because that content might be customized based on lots of different parameters.
- Robert Douglass
-----
Lullabot | My Drupal book | My Digg stories
Without any
Without any problem.
---
Tempri Design
The caveat is hardware
You're not going to have a community portal with 100,000 active, logged-in users, on shared hosting that you pay $10/month for. You'll need dedicated equipment for this.
- Robert Douglass
-----
Lullabot | My Drupal book | My Digg stories
Straight out of the box? I
Straight out of the box? I don't think any CMS would scale THAT much without any additional programming efforts... also, it depends on your hardware / what modules you want to use.
Biology News Net
---
e! Science News
Extra programming not needed
It really depends on what the site is supposed to do. There's no reason Drupal can't scale to 100,000 out of the box. A strong database server plus 2-3 webservers should be enough for most cases. If there are some really computationally intensive contrib modules that are thrown into the mix, then there needs to be more hardware. The only reason I can see that extra programming effort would be needed is if something like memcache is to be used. That is, by nature, a more invasive strategy, since one caches programming objects in memory, and that necessitates wrapping bits of code in caching blocks.
- Robert Douglass
-----
Lullabot | My Drupal book | My Digg stories
In my experience, some parts
In my experience, some parts of Drupal use unoptimized SQL queries (using temporary using filesort, not using index by EXPLAIN) that could choke a server if the database contains many entries (large temporary tables).
The various caches (mysql query cache, for one) kinda hide this fact, but some parts of drupal would really benefit from sql optimization. Not saying that Drupal is slow; but for large sites, if some temporary table ever gets bigger than available memory, any site is gonna hit the swap regularly and be very slow. As you said, if you have a very good hardware setup with gigs of memory and don`t use many "bad" contrib modules, i guess it could be OK.
I'm working on improving unoptimized mysql queries as I find them, but we should really get some mass effort going on this for Drupal 6.0.
---
Biology News Net
---
e! Science News
I dont think *any* CMS works
I dont think *any* CMS works out of the box. It used to be a good rule of thumb that you spent 50% of your budget on the CMS and the remaining 50% on consultants to set up your CMS/do coding/templating etc
:-)
Speaking from experience
Drupal can do this, and is doing it successfully on many sites. The most obvious case in point should be Drupal.org itself which has nearly 90,000 registered users. A much better example, however, is the recently launched http://www.mtv.co.uk site. Suffice to say that it has many hundreds of thousands of registered users, and they are very active on the sites with forums, videos, voting, competitions, private messages and lots of other great features.
What you need to have to do this is some hardware and some performance tuning. For 100,000 users you need, at the bare minimum, a dedicated database server plus 2-3 web frontend servers. I'm assuming that your site is going to take advantage of the "community portal" features offered by drupal, and that the majority of your site users will want to log in and do things. If that's not the case, you can get by with far less, as Drupal can be used to serve pages to anonymous users with far less overhead.
There are lots of other strategies that can be used to make Drupal scale. One of the ones I'm working on at the moment is using Memcache.
- Robert Douglass
-----
Lullabot | My Drupal book | My Digg stories
Hi Robert, I'm lurking on
Hi Robert,
I'm lurking on the memcache mailing list and am wondering what entities you are caching with memcache?
Presumably it is a lot finer grained than just web pages for anonymous users....
nodes, comments, taxonomy
The real exciting ones are nodes in node_load, comments in comment_nodeapi, and taxonomy objects (terms, vocabularies, trees). I haven't gotten to users yet, but think it is also possible. In sheer number of queries, caching drupal_lookup_path did a lot to reduce.
- Robert Douglass
-----
Lullabot | My Drupal book | My Digg stories