Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By solutionsphp on
Can anyone provide assurances about Drupal's speed and performance? I'm a little worried about deploying a lot of Drupal sites because so many of them seem so slow. Drupal.org, Lullabot, dead.net, and more including my own new Drupal sites... I frequently experience very slow load times on these. Is this a Drupal issue, or just coincidental?
Comments
I'm afraid it is Not
I'm afraid it is Not coincidental... Drupal is extremely flexible, but that makes its code "heavy" (I'll get cursed for saying this :-) ). I mean, Drupal needs to check sooo many things before it finally shows what you're after. That requires quite substantial servers, or database tweaking, or who knows what. Flexibility comes at a price, I'm afraid. There are dozens of threads on this site complaining about this issue.
One more or less good thing is that non-registered users suffer less from this speed issue, because static content can be cached. That does help, but on the other hand it makes it difficult to maintain a site with a lot of user interaction, because that would most likely require registration - and would cause a loss of speed.
Ludo
I appreciate your frankness,
I appreciate your frankness, Ludo!
Hopefully speed and performance will be addressed in v6.
Drupal is very impressive until a site slows to a crawl. At that point, users and clients could care less about the beauty of Drupal's inner workings--they just need a site that performs.
Loading up anything on Lullabot right now takes about 5 mins! That's pretty unacceptable.
My review of David Mercer's "Drupal: Creating Blogs, Forums, Portals and Community Websites"
The problem with Lullabot was external
At about the time you posted we were being "attacked" by an external address. I put attacked in parenthesis because we don't really know if the behavior was intentional, or just some automated program somewhere gone bad. In any case someone was downloading our screencasts repeatedly at such a rate that the site couldn't cope (which takes a lot... Digg front page didn't phase our server one bit). The problem was solved by James Walker simply by banning the one IP address that was sending all of the requests. As I check now, the page generation times are consistently under .5 seconds and often in the .2 second range.
Nobody will disagree with you that optimizing Drupal is a good thing. Believe me, many smart developers think about this all the time and many initiatives are underway. Configuring your LAMP stack correctly and choosing good hosting are also important elements of good performance. Finally, using only high-quality modules and themes makes a difference as well.
Hope you have a better Lullabot.com experience next time you visit.
- Robert Douglass
-----
Lullabot | my Drupal book
Hi ludootje, can you please
Hi ludootje, can you please explain or give some links about tweaking of MySQL database for a Drupal server? My server gets slow very frequently and my host said that MySQL has not been properly set. And since I have self managed server and I am not good at setting up the server, detailed information on tweaking servers for hosting Drupal websites would be very nice.
Hi Snegny, what you're
Hi Snegny, what you're asking, is a bit beyond my abilities, I'm afraid... There is a chapter on optimizing Drupal in "Pro Drupal Development" by Van Dyk and Westgate.
There may be some stuff on this forum, but that's about all I can tell you. These threads may be of interest:
http://drupal.org/node/52656
http://drupal.org/node/2601
Ludo
ludootje, thank you for the
ludootje, thank you for the links. i will take a look.
// Hopefully speed and
//
Hopefully speed and performance will be addressed in v6.
//
Good to hear about that :)
What are you seeing?
What sort of page times are you seeing on your own site for say the front page as a logged in user? Over 100ms ?
I can't speak for drupal.org and other larger installations that are running into performance issues, but with a couple dozen modules active on my test site I'm still seeing front page load times of 60-70ms as a logged in user. That seems perfectly acceptable to me considering the amount of power and processing happening behind the scenes.
You might be running into a module or two that are slowing down the works for you. If you install and setup the Devel module you'll see what query times and rendering times you have going on.
Also, like most PHP appliations, using an accellerator like eAccelerator with Drupal can make a huge difference. http://www.eaccelerator.net
will
will http://www.eaccelerator.net/ really work? is it reliable to install? did anyone? the last release of eaccelerator was made on 2006/02/15, too long ago, which makes me to little bit doubt.
Yes, accellerators like
Yes, accellerators like eAccelerator, MMCache, APC, PHPA, etc work very well. They do so by intellegently caching th PHP code in the *compiled* state so that virtually all of the overhead of compiling on the fly is eliminated. They typically realize a speed increase of 1X-10X depending on the code in use.
Take a look at this for some idea of the results, we're talking a 500-600% speed gain:
http://2bits.com/articles/benchmarking-apc-vs-eaccelerator-using-drupal....
Not sure what OS/distribution your using. But on something like Fedora Core it's as easy as typing "yum install php-eaccelerator" and then restart Apache/PHP.
If you're using MySQL you can also speed things up by using query caching if you aren't already. just add a couple lines to your /etc/my.cnf (assuming unix) like:
query_cache_type=1
query_cache_size=16M
and restart it. Queries where the information hasn't "changed" will be served from cache after the first call.
Also, in the Drupal admin there are setting to take all the CSS pages and include them as one compressed file. If you haven't done that yet, then you are likely serving out a large number of files with a given page.
There is also a setting for "caching mode" in Drupal's admin. If you enable that then pages for anonymous uses will be served quickly from cache.
That should get you rolling..
Moonshine, before reading
Moonshine, before reading your post I used performance possibilities given through administration page, but I had not used query caching.
I have just done it and hopefully will see some performance increase. For now it looks like working at the same pace. As for php accelerators I am going to try to install now. Hopefully it is not too much complicated (I am on Unix+MySql).
Thank you very much for your suggestions!
By the way, can you tell
By the way, can you tell which one of accelerators you mentioned (eAccelerator, MMCache, APC, PHPA, etc) is most suitable for PHP4+MySql server?
I've used eAccellerator,
I've used eAccellerator, MMCache and PHPA on different servers over time. Personally, I use eAccellerator and have never had any trouble (on either PHP4 or PHP5, Apache 2) On Fedora it's available via Yum and I'd be surprised if other distributions didn't have it directly available also. I'd be amazed if it didn't cut down your load times considerably. What OS are you using?
Yes, clocking in at well
Yes, clocking in at well over 100ms... often several MINUTES to load pages. My host investigated and said there are many processes left running, causing Apache to stall.
My review of David Mercer's "Drupal: Creating Blogs, Forums, Portals and Community Websites"
What are you seeing?
What sort of page times are you seeing on your own site for say the front page as a logged in user? Over 100ms ?
I can't speak for drupal.org and other larger installations that are running into performance issues, but with a couple dozen modules active on my test site I'm still seeing front page load times of 60-70ms as a logged in user. That seems perfectly acceptable to me considering the amount of power and processing happening behind the scenes.
You might be running into a module or two that are slowing down the works for you. If you install and setup the Devel module you'll see what query times and rendering times you have going on.
Also, like most PHP appliations, using an accellerator like eAccelerator with Drupal can make a huge difference. http://www.eaccelerator.net
I have about 10 modules
I have about 10 modules installed on my test site, on which I am the only user. My load times are always above 100 ms, often even close to 200 ms. From a flexibility and ingenuity point of view, Drupal is a gem, but I am afraid that its out-of-the-box lack of speed will eventually damage its reputation badly. Talking of speed, this site, drupal.org, which should be THE Showcase, isn't a speed demon either, is it (edit: it took about 20 seconds, not microseconds, but seconds, to submit this text...) It hurts me to write this, but I have seen so many speed concerns on this forum, and although there have been instances when a nifty change to the code could speed things up, the bottom line is that Drupal is an extremely resource-hungry CMS. And that's not good.
Ludo
Are you using a PHP
Are you using a PHP accellerator ? MySQL query caching? Performance settings in Drupal? If not, I just posted some additional information above that should shave your times in half at least.
As for Drupal.org, they are battling exponential growth with limited reasources. You can read about it on a number of threads including this one which was on the front page about a week ago:
http://drupal.org/node/163216
Or more recently this post on Dries' blog:
http://buytaert.net/database-replication-lag
At the moment it looks like they are battling the lag ssue with master/slave replication lag more then some direct Drupal issue. Most Web sites will not even get close to having issues of this magnitude.
=-=
reading Kbahey's threads prove fruitful see: http://2bits.com/. Often times it is not Drupal but the contrib modules being used.
2 cents
This is a good note; I had to disable the "Update Status" module on our intranet installations because we lost http access to drupal.org. Until then, I was seeing 2 minutes to the login screen. I know the problem is security-related on our side, but it initially made the site look bad.
Back to manual checks until the problem is diagnosed; too bad, loved the convenience. Oh well.
Has there been any
Has there been any performance benchmarking done on any of the contributed modules?
All good things must come to an end, enjoy them before they do!
on
on http://phplens.com/lens/php-book/optimizing-debugging-php.php it is said that
is this true? should it be just ob_start() or ob_start("ob_gzhandler") and where exactly to place this code?
From what I understand,
From what I understand, ob_start() etc. are not really to be considered as "speed boosts". The ob_(...) functions buffer the output before sending it to the screen. In regular PHP scripts you see the script gradually filling the screen. With ob_ functions, you see nothing, and then all of a sudden you see the whole lot. Maybe that gives the impression of being more speedy, but the risk is that your visitor, before the sudden screen appearance, will be staring at a white screen for a considerable time, thinking that nothing is happening. In gradual screen buildup he may at least have the feeling that "something" is happening.
The main reason for using ob_ functions, it seems, is to grab unforeseen error events, which would then allow for a cleaner redirect.
More info: http://be2.php.net/ob_start
Ludo
FWIW if you are looking to
FWIW if you are looking to GZIP compress page output, you might want to look into mod_deflate for Apache. It has advantages over doing a blanket compress statement in PHP, and can compress whatever Apache output you want:
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
Chances are it's probably already installed w/ your Apache install.
Lullabot.com, Drupal.org
At the time that this post was made (August 24, 2007), www.lullabot.com was in the midst of a DoS attack. The situation has been resolved and I think that you'll find the site is actually quite snappy.
As for Drupal.org, the site is rated as the 801st most popular site on the internet by Alexa, yet we are operating off of donated hosting with VERY minimal hardware. This is a known issue which the Drupal Association is in the process of solving. If you would like to help speed up drupal.org, please donate to the Drupal Association.
I think that you'll find that with adequate hardware, optimization, and proper architecture, Drupal can perform as well or better than most dynamic content management systems.
--= Jeff Robbins | www.lullabot.com =--
...
To add to Jeff's note.
http://www.workhabit.org/how-do-you-support-500-000-users-drupal
-Steven Peck
---------
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
I have never seen a fast drupal site
Please prove me wrong if you know of an example! Post links to fast drupal sites for everyone to see... Drupal is lovely and intuitive for a programmer like me, but AMAZINGLY SLOWWWWWWWWWWW for any real usage scenario.
AND NO PEOPLE! 3 second delay is UNACCEPTABLE. Period. Get real.
Show me a fast drupal site.
...
Wow, caps and everything. I suspect you will find fault with my list with your capitol letters and I don't have time to do more then pull these three off the top of my head.
http://www.mtv.co.uk/node/24580
http://www.theonion.com/content/
http://www.nowpublic.com/
Speed depends on content, images, your network location in relation to the serving sites, current site load (sale, online concert, DOS). Read the article I linked earlier about how to size your site.
-Steven Peck
---------
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
Caps aside, you're honestly
Caps aside, you're honestly seeing 3 seconds to render an normal Drupal page? (as clocked by something like the Devel module) As another "programmer", I can assure you that something is definitely wrong if that's the case. Even on my "slow" development servers I see rendering under 80ms for something like a node page. How about some info:
Drupal 5 ?
PHP5 ?
Apache 2?
PHP accelerator?
MySQL caching?
Drupal performance caching enabled?
Drupal CSS bundling enabled?
Or is this just based on drupal.org? (which has been discussed many times)
So lets be honest here with
So lets be honest here with everyone....
How do you know which modules are "High Quality" ? Any popular modules that are a hog on resources and not such great quality?
=-=
There are far too many modules to check each one , one by one and grade on "quality". Views can be resource hungry. CCK can be resource hungry. In these cases if you know how to create your own custom content type in a module, its probably better to do so. IN regards to views, if you know how to write your own DB querries, its probably better to do so.
In fairness to contrib module developers, if noone takes the time to test, benchmark, report back the findings then what is a developer to do ?
All of the modules are written with the best intentions, very very few modules, have a team behind them. Most are written and maintained by a sole individual who in some cases is taking the time to learn, drupal, and php. Not all modules are designed and coded by professional, seasoned experts. Some are designed and coded by people just getting their feet wet and learning as they go along.
to answer your questions in a more specific manner:
How do you know:
you benchmark the site before and after a module is installed. you benchmark with low and high traffic , you benchmark until you can't benchmark no more : ) Then you come to an educated decision and hopefully find a way to either make the code perform better or refactor it to increase performance.
i had the same problem and
i had the same problem and after i have disabled the update-status module it runs very well!
Hello everyone, it may be too
Hello everyone, it may be too late to comment, but putting this configuration in the MySQL (8), Drupal is super fast! I hope someone works:
[mysqld]
...
...
table_open_cache=2000
tmp_table_size=85M
thread_cache_size=10
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=159M
key_buffer_size=84M
read_buffer_size=64M
read_rnd_buffer_size=256M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=50M
innodb_buffer_pool_size=232M
innodb_log_file_size=48M
innodb_thread_concurrency=9
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
join_buffer_size=256K
max_allowed_packet=128M
open_files_limit=4161
sort_buffer_size=256K
table_definition_cache=1400
innodb_flush_method=1