By Tommy Sundstrom on

Using this site I can't help notice that it is quite slow. Moving from page to page, as well as searching, takes significant more time than most other sites. Is it just me or do other have the same impression?

On my own experimental site, Drupal is as fast as anything - but there is no load, just one user.

So, is the slowness of drupal.org a result of

- my imagination?

- underdimensioned hardware?

- to much show of personalised features?

or is Drupal itself that is slow under load?

EDIT: Changed title to say Drupal.org instead of just Drupal (kbahey)

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented

There are currently 43 registered users surfing drupal.org. If you consider that most of a page is generated from the database for each page view (and a lot of code is parsed) then you will understand that this puts quite some load on the server.

Drupal as such is quite fast.
--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

Tommy Sundstrom’s picture

Tommy Sundstrom commented

As most users of web sites I don't consider anything about the technical underpinnings. It takes noticably longer to reach a page on drupal.org than on other sites - so it's slow. On a technical level, I'm sure there is a lot of impressive things going on, but I don't care. Slow is slow.

Should I conclude that Drupal does not scale, and that it's unsuitable for a site expecting trafic in the range 40 registered/400 guests or more? Or that personalization should just be used on low trafic sites?

Or maybe it's just the hardware at drupal.org that is not dimensioned for the load. I know there is no money to pay for fancy hardware. In that case it's a pity, since many people will get the wrong impression of Drupal.

killes@www.drop.org’s picture

killes@www.drop.org commented

I don't know what the hardware is that Drupal runs on. There are probably several tweaks that could be done:

  1. Upgrade MySQL (currently 3.x ) to 4.x. 4.x is said to be faster.
  2. Get faster hardware

    3. and

  3. make Drupal faster.

There has been a comparison of different OS CMS projects where Drupal did fare quite well so I assume that it is this server that is a bit stressed.

We of course always welcome contributions for making Drupal faster.

--
If you have troubles with a particular contrib project, please consider to file a support request. Thanks.

--
Drupal services
My Drupal services

cogumbreiro@gnome-ppx.berlios.de’s picture

cogumbreiro@gnome-ppx.berlios.de commented

I've just ported a site from Plone to Drupal because it was way faster.

aarplane’s picture

aarplane commented

Just maybe this server is a bit slow or the bandwidth is very high....

carlmcdade’s picture

carlmcdade commented

Spreadfirefox.com is fast even with all the users. So it is a server thing probably.
---------------------------
info for Drupal installation
__________________________
Carl McDade
Information Technology Consult
Team Macromedia
www.heroforhire.net

marky’s picture

marky commented

It wasn't very fast today as it got slashdotted again. This helps explain the slowness of this site today - the affiliate button in the right column takes ages to load for me on a dsl line because it's coming from a slashdotted server. A good argument against hotlinking images, methinks ;)

/marky

red_eye’s picture

red_eye commented

I find it to be quite fast on my site when there are no users and I run on a shared host that is normally under a linum top style cpu load of 2-6.

Tommy Sundstrom’s picture

Tommy Sundstrom commented

Aparently, it was the server - old hardware and running web and db on the same machine.

Torenware’s picture

Torenware commented

Recently, I've noticed a real drop off in performance of the drupal.org site. I'm assuming I'm not the only one.

Any reason in particular that the site is slowing down? Has some new feature been turned on, or are we just getting too big for the current server hardware?

Rob Thorne
Torenware Networks
http://www.torenware.com

Rob Thorne
Torenware Networks

bslade’s picture

bslade commented

Excellent question.

Does anyone have any experience with how many simultaneous "average workload" users Drupal can handle? Is it 40, 400, or 40000?

As long as I'm asking questions, how about: how much slower and computer resource intensive is a cached Drupal page fetch versus a fetch of a simple flat file HTML page? Eg. does it use twice the page fetch time and twice the CPU time? Or ten times as much? (including MySQL cpu cycles)

And finally, I assume throttling is a good measure of when your Drupal website is maxing out. Is Drupal.org throttling? I always thought there should be some subtle indication of throttling to the end user so that they can report it back to the webmaster. Maybe the "this page was throttled" indicator could go right next to the "Paypal Donate" button ;)

PublicMailbox dot benslade.com
(append 030516 to the subj to bypass spam filters)
"It's the mark of an educated mind to be moved by statistics"
Oscar Wilde

bonobo’s picture

bonobo commented

have been asked in the past (albeit for different versions of Drupal).

For example:
http://drupal.org/node/1367 and
http://drupal.org/node/7368 and
http://drupal.org/node/13733 (Drupal and Plone)
and this thread on replicated databases/db clusters: http://drupal.org/node/23289

Most of the questions do not address all (or even some) of the variables that could affect speed, such as the hosting environment (shared vs. virtual private vs. dedicated vs. self-hosted, etc), db speed, server speed, etc.

Scalability is a difficult beast to pin down precisely because of all the variables that could affect site performance, and therefore how well a specific site might scale. When you start to factor in the different performance of different modules, it begins to get increasingly complex to make meaningful comparisons.

With that said, I would love to see a discussion that breaks down some of the potential bottlenecks that could affect the performance of a Drupal site.

I get the impression that most people are interested in getting accurate info re numbers of users for a Drupal site. For the reasons I described in the preceding paragraphs, it would be difficult to lay out precise numbers, but if the the potential areas that could slow a site were described in more detail, it could allow site admins to make more informed choices about how to maximize the performance of their sites.

Cheers,

Bonobo

-------
http://www.funnymonkey.com

bslade’s picture

bslade commented

I was working on a site that was getting on the order of a million page views per day (see the beginning of June 05). We kept having weird problems with Drupal and MySQL. Slow page accesses, tables getting corrupted, lots of Drupal duplicate cache insert errors, too many connections to the MySQL server errors.

The business owner of the site was completely freaked out and getting ready to switch to the Wordpress blogging software.

One fix we made was to change php.ini settings so that 25 Mbytes per php process were being allocated. This helped, but didn't completely fix the problems.

Out of desperation, the admin's wrote a script to create file copies of the 20 most recent Drupal nodes, and modified the web config .htaccess file to automatically reroute Drupal requests to the node cache files, if they existed.

This made everything work great. Page views per day jump by a factor of 4, and the site always had instant response. Click here to see the site.

Right now, I'm working with another site which might be having the same problem. I'll see if the file caching makes this other site happy to.

Ben inDC

sepeck’s picture

sepeck commented

I shall also mention that this post predates by more then a year the server move to the new servers that occurred (a month ago) recently. That said, in a new thread or the handbook perhaps, any methods of optimizing server performance on the new 4.7 (or even 4.6) codebase is welcome. Let us know.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

killes@www.drop.org’s picture

killes@www.drop.org commented

File caching is not new to Drupal but never made it to core:

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/jeremy/fileca...
--
Drupal services
My Drupal services

--
Drupal services
My Drupal services

dumell’s picture

dumell commented

One Drupal 4.6.3 site I'm responsible for just went down because the MySQL server got overloaded.

We're running it on two (!) quite new dual-Xeon front end servers (Apache 2.x) and one dual-Xeon MySQL server (v4.x) with 4 GB of RAM. Two front-end servers works since we are using a load-balancer and they both use the same mounted file system.

The front end servers are not having a problem with the load, but the MySQL server has. The site has some 50.000 nodes and 80.000 comments and anonymous users are not allowed, only authenticated users are allowed.

With about 50 logged in users, the MySQL server gets overloaded. We are expecting more from this hardware.

Allowing anonymous users would make use of the Drupal caching mechanism, yes, but that is not an option in our case - we need to be able to serve more authenticated users.

The problem is SQL queries that scans trough the node_access table (we are using og.module) and the comments table without using a key/index. With 50.000 and 80.000 rows in these tables, scanning trough them for every page change overloads even this hardware. With only a few users, these queries takes 2-6 seconds but as we hit some 50 authenticated users, these queries starts piling up and are getting cued and the queries starts taking over 100 seconds each. The MySQL server is not swapping but keeping everything in memory.

Databases is not my specialty, but I was told that the part of the problem is that the queries are scanning trough these large tables without making use of an index/key.

Are we doing something wrong when the queries in our Drupal scans trough all lines in these tables? Can we make (better) use of the cache even when we have only authenticated users (in 4.6.3)? Is there something we can do to make Drupals queries more MySQL friendly?

sepeck’s picture

sepeck commented

I would suggest starting a new thread rather then resurrecting a year old one that was specific to Drupal.org itself. I don't know enough about optimizing Drupal to answer your question itself.

-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

dumell’s picture

dumell commented

Yes, thank you for the comment. When I wrote my comment, I did not notice the original posting was over a year old, I just noted the last comment that was quite recent. I'll make a new post about this issue.

yngens’s picture

yngens commented

dumell, could you please give a link to the new thread - i would like to follow discussion of your post cause i believe i have the same problem. thnx.

prameya’s picture

prameya commented

i dont really notice it otherwise.. but searching is "kinda notice-bly" slow... no hard feeling.. i love drupal though... :)