Why is Drupal 7 so slow? [closed]

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

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 5

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 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

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 8

Logging out of admin and making sure all admins were logged out fixed my response issues for anonymous users. I'm using a few basic modules and drupal commerce installed. Site is not really that large and it's only 2 admins. But noticed when an admin is marked logged in, the site doesn't respond for about 5-10 seconds for everyone, everywhere. Logged in or not. May or may not help everyone, but for some people, might solve some headaches. I would like to know why though if someone else knows. I'm figuring as an admin, I must have something enabled when logged in that it does some sort of re-caching, processing or something that I'm not aware of. That's my 2 cents, hope it helps someone.

Answer 9

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 10

I had that issue (10sec to first byte) on a production server when a developer had set the domain name as database server and not the hostname of the database server in the settings.php ...

Watch out!

Answer 11

As others have mentioned, once you've gone beyond a trivial site Drupal is rather resource hungry. Specifically, even with Drupal's cache and tools like APC, each request still involves many database queries.

Depending on your traffic profile, I'd recommend using Varnish in front of Drupal. For anonymous (i.e. non-logged in) users this will serve cached pages blisteringly fast, typically <200ms. Logged in users will need to bypass Varnish, but by taking a significant load off Apache/PHP/Drupal/MySQL, you'll see improvements here too.

Answer 12

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 13

If you're on a Dedicated/VPS server, set your PHP Handler to FastCGI (fcgi) or similar.

Many servers, by default, set the PHP Handler to SuPHP. SuPHP is slow, does not work well with memcached and will often bring your site down, upon traffic. The difference is huge; I learned it the hard way.

Answer 14

If you can't install Varnish, Alternative PHP Cache (APC), Memcache or other modules that require server side software, I advise you to install Aggregate Cache, Entity Cache & File Cache.

These modules do not require any software to be installed server side and they work pretty good improving the performance of the built-in cache system. I have tested all of them on production site with Drupal 7 and they are stable enough.

Note: Advanced CSS/JS Aggregation should give you better results but it introduces a lot of bugs because it hasn't been correctly ported to Drupal 7 yet. I have never tried Boost or Alternative Database Cache (ADBC) to be honest.

Answer 15

I'm new to Drupal, as in a month.

I recently had some really serious hanging issues with Drupal 7 with pages taking close to 5-7 minutes to load.

From the Admin side it would hang for close on 20 minutes. I tried clearing Cache but could not and got a Bad Gateway message.

I then tried repairing tables, but accidentally selected "delete" and lost the whole lot - lucky I backup before hand.

For someone who does not know Drupal some of the solutions I have found can be rather daunting or PhpAdmin for that matter.

I found an easier and less complicated way - not sure if it's the correct way, but I found hanging issues and slowness completely vanished once done. If anything once you have a backup you can always revert.

Pages now load on both the front and back end within 1-3 seconds.

Please note: I'm on a shared server (MediaTemple), so this may not work for people on dedicated hosting.

1. backup the database
2. open the .sql file in TextEdit / Espresso / equivilant
3. find and replace " INNODB " to " MyISAM "
4. save
5. go back to PhpAdmin click on database
6. dump / empty / delete tables (not sure which is correct)
7. upload the .sql file that you have changed

The whole process should take no longer than 3 minutes.

I found the solution here:

http://anthonymclin.com/fixing-hangs-drupal-admin-media-temple-hosting

Hope this helps someone else.

Answer 16

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.