Why is Drupal 7 so slow?

Question

I just created a new Drupal 7 website and the loading time is too much. I checked with Speed Tracer from Google and here are the results for the first page:

URL http://mysite.com/
From Cache  false
Method  GET
Http Status 200
Mime-type   text/html
Total Bytes 
Request Timing  @63757 ms for 3331 ms
Response Timing @67088 ms for 379 ms
Total Timing    @63757 ms for 3710 ms

3710 ms is too much for loading a home page on a production site.

Does anyone have the same experience? What should I do to improve the speed?

One speed-related problem was in MySQL configuration file: my.cnf.

Now I have set the following variables for MySQL relative to InnoDB:

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
set-variable = innodb_flush_log_at_trx_commit=0

So the site is fast now. However, sometimes for a reason I don't understand, the site is giving me a blank page when I load a page. After refreshing a couple times, the page will be displayed.

I am thinking that timeout setting for InnoDB could be the problem. What's your opinion?

Now I have an incredible waiting time here: 10760 ms on http://localhost/mysite/user:

URL http://localhost/mysite/user
From Cache  false
Method  GET
Http Status 200
Mime-type   text/html
Total Bytes 
Request Timing  @12090ms for 10471ms
Response Timing @22561ms for 288ms
Total Timing    @12090ms for 10760ms

There are some strange things because the problem is not with the Response Time of Drupal, which is 288 ms (reasonable I think) but the Request Time, which is 10471 ms

Why is the Request Time so long? And what causes this?

Here are my settings and modules:

APC installed/enabled and Cache pages for anonymous users, Cache blocks, Compress cached pages, Aggregate and compress CSS files, Aggregate JavaScript files all enabled

I have the following modules installed:

• blockify
• ctools
• google_analytics
• i18n
• languageicons
• metatags_quick
• nice_menus
• omega_tools
• page_title
• pathauto
• site_map
• token
• variable
• views
• webform
• wysiwyg
• xmlsitemap

Answer 1

There are some performance issues with Drupal 7 currently on some server/server configurations.

As a start, you could try the 7.x-dev snapshot to see if there are any improvements.

Is this shared hosting, your own server, local development environment?

Did you already use Drupal 6 in the same environment?

Did you enable the basic performance settings, like aggregating css/js?

To do anything more, you will actually need to figure out what exactly is slow, there is often a specific bottleneck that is slowing down the whole site. As a start, you could enable devel.module and the query logging to see if there are any slow queries on that page.

If this is your own server, I strongy suggest to install and enable APC.

Answer 2

Most probably, you are hitting Avoid re-scanning module directory when multiple modules are missing. It happens if you have some missing modules in your installation. Try to check your system table:

SELECT name, filename FROM system WHERE type = 'module' AND status = 1 ORDER BY filename

And clean-up any modules that are still enabled but missing from the filesystem.

Overall, Drupal 7 is way more resource friendly and scalable then Drupal 6, other than some unfortunate regressions like this one.

Answer 3

Its not drupal, its probably your server at fault. Its true over the time drupal has evolved to be a resource hungry. But its only till you precise it that way.

the fact is that drupal 7 is infact very resource friendly in my experience

I used drupal 7 on a vps with memcache, Apc installed and it flew like anything.

Drupal 7 is optimized out of the box for large website featuring advanced cache features, reverse proxy, load balancer. You would say that this would make drupal 6 too fly, but there is noticable difference between drupal 6 and drupal 7 performace with same high end server setup.

From the satring I have been using drupal with more than 64 MB's of RAM and hence I didn't have much problem with drupal.

Drupal 7 may let you down initially, but given the proper hardware and software environment, you can do wonders with drupal in terms of speed.

Answer 4

Drupal 7 uses too many files. And like D6, it uses also too many SQL queries (in comparison with other CMS). So the first hit could take time, especially when you have a slow disk and files are not in OS cache.

In a normal situation, when cache is available, everything should be ok. There are many layer of cache: OS cache to avoid reading PHP files, opcode cache (like APC, not enabled by default) to avoid re-parsing PHP files, MySQL cache to avoid re-execute queries multiple times.

Answer 5

i18n is a troublesome module, because of its interaction with nearly every query being passed to the database. This may be a problem in your case. But it may be no problem at all. Some other modules may be problematic too.

My first step when performance-updating is to check the database. Turn on MySQL slow query logging and normal query logging (not on production!!) and run some spider over the site (or click trough 20 pages or so). Do that for both an authenticated and anonymous user.

You can then investigate the logs. Sometimes just peeking into the logs already shows many problems; such as 2000+ queries to render a frontpage (not unthinkable!). Or a slow query being hit over and over.

Next step is to use a tool such as MySQLsla to create some reports on what goes on in the database.

Next, trace what module fires queries. If you can lead a certain problematic (set of) query/queries back to one module, consider disabling that module, or rewriting it.

If that has not helped you, investigate if some module interacts with the queries or changes some important behaviour. e.g. i18n is known to interact with queries, turning otherwise quite lean queries into slow queries. Organic Groups is also one such module.

Only when you see the database having no problems, continue the search for performance-issues in the rest of Drupals code.

Answer 6

I notice the same problem with all my Drupal 7 installations: If your request sometimes takes so long it is because the cron tasks.

In Drupal 7, the cron is attached to a user visit; so, if your cron is set to fire every 1 or 3 hours, your are going to get a long request time. The cron wil check if there are new modules, re-index your DB, etc.

You just have to set up a call to cron externally and disable your cron.

Answer 7

I've found this post and it can be useful for you.

There should have no negative impact on performance for Drupal or any other web app, provided that PHP 5.3 has been properly configured.

If you've done any php.ini configuration whilst using PHP 5.2, be sure to read the cautionary note under GatorJacob's PHP 5.3 Support "sticky" in this same forum. Failure to clean up any such "EasyConfig" remanants prior to the version changeover is likely to use incorrect paths and other settings that could certainly affect the end results quite drastically.

Answer 8

It has been my experience that the hosting provider is the key with Drupal. I would do some of the tweaks listed above, but only got slight performance increases. Boost (and Boost Expire) helped the most, but still had performance issues on the admin side, even crashes.

I switched my hosting from GoDaddy to HostGator and everything runs so fast now! I was very happy with GoDaddy's service, and was reluctant to switch hosting, but that was indeed the key! I'm quite ignorant about hardware/memory/etc, so I can't tell you what particular spec is better, but it works for me!

I service multiple clients, and now refuse to host anywhere else. The site just won't perform properly, and I don't want to have to make a million tweaks to get something barely acceptable!

This isn't an anti-GoDaddy or pro-HostGator post...I'm just highlighting the fact that I got a remarkable performance increase just by changing my particular hosting environment.

Answer 9

i experienced this the other day with a website. It turns out that the my host was CPU throttling the site.

Also, it doesnt say that you have global redirect but (in case you do) I found that it doesn't play nice with i18n.

Answer 10

Drupal is a hungry beast. Most web servers aren't configured to give PHP the amount of RAM it requires. Go into php.ini, increase your memory limit to 64M, and see how that goes.