Hi Folks,

I just installed D7 and even if it looks quite nice, unfortunately it is very very slow. I installed it on the same server, running from the same DB, where I have a D6 test-system running (only D7 having 'drupal7_' as table-prefix), and the "respondiness" of D7 while travelling through the new administration-structures is really annoyingly slow.

On the D6 system, activating modules, adding translations etc. is clicking on "Save" and after at most a few eyeblinks, the system is ready.

On D7 it sometimes runs into Server-Timeouts (browser not loading anything anymore, overlay-content not progressing anymore) but at least every click to a different administrative link takes several seconds (in double-figures). After disabling the "Overlay" module it got a little better, but still is quite too slow to be appropriate for endusers (customers).

Just as an example: just clicking on "configuration" takes 11 seconds to show the configuration page in D7. In the D6 system (same server, same db) I didn't even reach the "two" while counting the seconds.

Server is Apache, MySQL is 5.0.91, PHP is 5.2.14. My System is a Dualcore with 3,2 GHz, running WinXP and D7 is slow in every Browser (Opera, Firefox, Chrome, Safari, IE), so the problem seems not to be related to slow JS on my System/Browsers.

Are there some "tricks" to speed up the whole D7 so it reaches the old D6 speeds? I installed D7 with the standard install profile, maybe there are some modules now active, that I should deactivate? Do "Contextual links", "Dashboard" or "RDF" have impact on Drupals speed? Or should I remove that "testing" folder in "profiles" and "tests" in "themes" to bring the system up to the old speed?

And another question: the "toolbar" is something like the "admin" module in D6. But then why is the toolbar not dropping-down it's subcontents? Is there a point somewhere, where I can configure it to do just right that? Would be reasonable when hovering over a menu-item that that item would expand it's sub-items. Just showing the main-items seems senseless to me. A normal menu could do that, so why is the only benefit of a js-menu like that missing? Or can I enable drop-down somewhere?

Would be nice if someone could help me.

Regards Paddy


timonweb’s picture

yep, noticed that too...I'm afraid to think that Drupal 7 is too slow, but I'm afraid it is. Any thoughts on that?

timonweb’s picture

Ok, a little update on the problem, disable Update Manager module and see how it goes. It turns out that Update manager likes to 'eat' resources :)

Jxff’s picture

I just installed D7 and was surprised how slow it was. I installed through Softaculous and the Update Manager was already off.

timonweb’s picture

I'm not happy with the overall performance also. Comparing to D6 mysql performance improved, but PHP performance dropped by almost two times and the main reason here, I guess, is the new theme layer which in change for a bigger theme flexibility adds an additional overhead.

youkho’s picture

Same for me Drupal 7 was very slow then i disabled 2 modules Dashboard and Contextuals links now seems to be a faster but to be honest i'd stick to D6.

roy smith’s picture

I hate to say it, because I've been waiting for D7 for so long, but it's so slow it's basically unusable. I've got a new site I put up to experiment with. It has no optional modules, a single user, three pieces of content, and essentially zero traffic at this point. Page loads take as long as 10 seconds.

Xandrean’s picture

It's slow for me too, but there has to be something else, either a glitch in D7 or a missing setting that has to be used on the server to make D7 work fine. I refuse to believe they could release such a snail.

samedgecombe’s picture


I have just upgraded to D7 via an auto-installer (Softaculous) but I get this error

This webpage has a redirect loop.

The webpage at xxx has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Here are some suggestions:
Reload this web page later.
Learn more about this problem.
More information on this error


I tried clearing the cookies and allowing third-party cookies, but no joy. Any ideas?

Jimmel’s picture

Not too sure about the rest of you but i don't find it slow at all, just exactly the same as Drupal 6. Running it on wamp 2.0.

nuez’s picture

I have also the experience that D7 is slower than D6, but after some tweaking I think the difference is minimal,

I have drupal running on a shared host, based on comments of other people and my own experience:

Drupal is slow Client Side because some modules use javascript and weigh heavily on your own CPU, so:

  • 1. switch off the overlay module
  • 2. switch off the toolbar module (which always hovers over your page at the same position, don´t know if its javascript of absolute CSS positioning, but it makes it slow) and install the administation menu module. It works better and faster.

and Drupal is slow because of Server Side Caching and things

  • Switch off the Devel modules if you have them installed
  • switch off the Update Manager Module

Now my Drupal seems still a bit slow on admin pages (with several modules installed), but not much slower than D6.

Freelance Drupal Professional @ Nuez Web

bhill9270’s picture

I'm running xampp 1.7.4 with D7 and did the things you stated above and I'm seeing a big difference. I'm using MDD hosting as well.

Thanks neuz!

Andy Wyer’s picture

I have just upgraded to D7 via an auto-installer (Softaculous). On an Apache Server. I had to manually put file rewrite.script to go anywhere on the site other than the frontpage.

The D7 site is 3x slower than a D6 site on same server, if I use MySQL 5.0.58, 32 bit for the Database.

If I use MySQL 5.0.58, 64 bit the D7 site is as fast as the D6 site, although I sometimes get lots of warnings along the lines of:
Permission denied in drupal_rmdir() (line 2277 of ..../ethengi.com/web/includes/file.inc) Particularly when I ran cron a few times in the beginning.

It could also mean the 64 bit MySQL server has less traffic and serves me better?

Also remember to go to yoursite/1#overlay=admin/config/development/performance and make sure you have a few pages cached and ready to serve up.

ps. After using Softaculous. Because I'm starting from scratch. I change the location of the location database by re-installing /install.php and /sites/ folder. Create a blank database and run the Drupal installer on my domain.

samedgecombe’s picture

Okay Andy and cheers for your reply. Not really sure that I understand your PS. In my case, I'm not starting from scratch. I have a load of data in a database which I do not want to loose. The install gets stuck in the install.php and Chrome shows this

This webpage has a redirect loop.

The webpage at http://selkirkrfc.doktorera.nu/install.php has resulted in too many redirects. Clearing your cookies for this site or allowing third-party cookies may fix the problem. If not, it is possibly a server configuration issue and not a problem with your computer.

Here are some suggestions:
Reload this web page later.
Learn more about this problem.
More information on this error

zack85’s picture

I find it a good bit slower too. I cannot see any reason to use drupal 7 over drupal 6 if its running a good bit slower. Page loading times are extremely important. The end user doesnt care that the Form API or Theme API are now more powerful or have improved code under the hood. All they see is a slow website. And if there's one thing that puts people off websites its slow page load times.

sephuriel’s picture

My site was extremely slow and I was considering not using drupal 7, I search for many days to find a solution and could not. So, I took it into my own hands:

Uninstall any drupal server stack that you may have ie. acquia stack.

Download and install XAMPP from apache friends.

Setup localhost and your drupal by moving the drupal site folder to the folder in XAMPP called HTDOCS.

Setup a new database, username, etc.

Go to the localhost/drupal or what ever you call it, in the internet browser of your choice.

Perform the standard installation.

Thats it, the site will now run faster than drupal 6 without the need to remove, uninstall, or disable anything.

Hope this helps!

Xandrean’s picture

That's good to hear, but It would still be interesting for the devs to find out what was wrong, as many users can't/wont reinstall their whole web stack to make Drupal 7 work. There has to be some kind of glitch in there, or an option that is not checked. Oh well, here I go again.

Also XAMPP is mostly just for development purposes, as the site states, it contains several security flaws that have to be fixed after installing it on a normal work server.

WillHall’s picture

Drupal 7 introduces quite a lot of new client side javascript - client side javascript depends on the power of your local machine to run smoothly. The weaker your local machine the slower the javascript functionality is going to appear for you. Javascript can be really cpu intensive, bear in mind that you are likely already running a large portion of background processes and your system is probably getting up in age. If that is the case: simply disable the fancy admin and you should notice the system speeds up for you.

While it would be ideal if everyone could run the latest and greatest everything -- it simply isn't a practical assertion. I run Drupal 7 on several mac, pc and nix desktops/laptop/mobile systems and I can only see a hindrance to performance on the systems that are nearly ready for a fresh install of their designated OS.

In summation: I call shenanigans.

Xandrean’s picture

Finally found the time to look deeper into the issue at hand. Tried some random variable changes on InnoDB in my.cnf file and setting innodb_flush_log_at_trx_commit=0 helped me fixed the problem. It seems that a value of one means every transaction is written to the log as opposed to writing a complete transactions log every second when using 0. Neat!

adroid’s picture

Setting innodb_flush_log_at_trx_commit to 0 or 2 helps to speed up db writes a lot.
Of course this setting produces slight risk of data corruption on MySQL/system crash...but INNODB recovery log should help anyway...so I see no problem. :)

alfonso100’s picture

I was having slooooow page loads, I mean very slow: page execution time was around 235995.3 ms, 265675.5 ms; after editing my.cnf typical page execution times are 706.26 ms, 789.12 ms, 746.18 ms

lancerkind’s picture

It takes up to 2-3 minutes after clicking "save" on site configuration tasks.

I'm not using InnoDB, so that won't help me. Mysql 5.1.47-community.., PHP 5.2.16.

I'll try a few of the other things people suggested. Otherwise, I'll work on my Drupal 6 site until I learn how to make it fast.

Xandrean’s picture

MySql 5.1 should come with the InnoDB storage engine included. Have you specifically disabled InnoDB during D7 install? If not, then you have InnoDB but it's poorly configured, as D7 wouldn't probably work at all. Check the list of storage engines in PhpMyadmin under the Engines tab, it should be there.

lancerkind’s picture

Thanks for pulling me out of the weeds regarding InnoDB. I see the settings you mentioned. (When I didn't find the config file you mentioned in your previous post--I was only looking in the Drupal file tree--I assumed InnoDB was a MySql alternative.)

I'll try out the settings. Strange thing is that the site is running OK this morning. When I first installed Drupal 7, it worked fine to, but when I started configuring the system "in anger" everything slowed to a crawl. So something else is adding to my bad performance, beyond the DB. I'm on BlueHost (which I think is great, BTW) and I noticed that CPU throtteling was kicking in on my slow day. I sent a ticket in and they said:

It sounds as if your account simply engaged the throttler. This will happen at any time that your account attempts to use more than 20% of any of the server's CPU cores. Reducing your CPU usage should reduce incidents such as this.
Please let us know if we may be of further assistance.

The process that was throttled was (if memory serves) index.php for the Drupal 7 site. I don't see anything about mysql being throttled, so this is PHP activity. I'll keep an eye on things.

Here's some other info I found about innodb_flush_log_at_trx_commit:

Drupal benchmarking with different settings: http://drupal.org/node/817398
Details on what the parameter is doing (ACID requires 1, though read the details to understand what you're giving up with settings != 1) http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_inn...

Xandrean’s picture

Yeah, setting it to !1 break ACID, but on my site it's not mandatory, as I can always load a backup if needed. Try disabling some modules and see if that helps throttle the cpu a bit.

There's also the devel module that can log the database access time and I think it can also show cpu and memory, so you can try installing the module for troubleshooting. I used it and found out the bottleneck was the database in my case.

timonweb’s picture

Well, you need to accept the obvious fact: Drupal 7 isn't for a shared hosting. point. Look for cheap VPS, like a Linode 512MB for example. It's perfect for Drupal 7, you can install APC and make this pretty snail run like a cheetah.

lancerkind’s picture

Thanks for the ideas. Especially APC (a PHP caching mechanism).
Right now I'm prototyping and maybe I'll host the production site on BlueHost, or maybe I'll move to Drupal Gardens. It's not a good sign if a single user can't get enough performance to build simple proof of concepts.

It's been three days and I haven't faced the 2-3 minutes slowness I had that one day. (I'm monitoring the server now, maybe someone else was hogging cycles.) As of now, it's OK... (maybe takes 3-4 seconds, only once today did something take 20 seconds). No worse than my non Drupal 7 sites on the same server.

What version of Drupal does Drupal.org use?

ryivhnn’s picture

I think it uses Pressflow, and still on v6 itself (anyone that's ever upgraded a Drupal community site should appreciate the amount of work that goes into an upgrade, and there's five bazillion people and projects kicking around this site).

I notice that a lot of people with performance issues seem to be on cheap shared hosting and getting extremely defensive of using that option. Drupal is a bit of a monstrosity/resource hog for cheap shared hosting, but in all seriousness I wouldn't be using cheap shared hosting for any site for any reason unless recommended by someone I trusted as giving good performance almost all of the time. But I may be biased from having some dodgy experiences with cheap shared hosting where my websites just stopped working when America woke up during Australia's night.

Another common trend I've noticed is using Softaculous or some other installer type thing to install Drupal. I don't trust those things either, they seem to create more headache than time they save by apparently making things easy. Go ftp :)

Drupal definitely does NOT need a vps to run smoothly. I have a reseller account which may make some difference but I'm definitely on shared hosting (was eyeing off vps because it's a vps but couldn't justify the cost) and no complaints whatsoever from any of my clients. All my current clients with Drupal sites live on Christmas Island with something like a 128k internet connection and they would really notice a slow loading site. One of the sites that I've built for a community based in Western Australia (where I live) aren't reporting any performance issues at all and I haven't yet turned on Drupal's caching options for that particular site. I haven't needed to seriously look into caching modules (though I've started looking purely out of interest because I have a strange addiction to optimising) for any of my sites, but they are all pretty small.

works at bekandloz | plays at technonaturalist

lancerkind’s picture

Things were moving along nicely all my morning and early after noon, but now (1500 BeiJing time) my slowdown is back. I think Drupal 7 is stressing the resources of my hosting service (BlueHost). CPU throtteling is happening and it reports "/ramdisk/bin/php5 .../index.php". This wasn't occurring with Drupal 6, so you can see why I'm a bit "finger pointy" as Drupal 7 is the new variable.

Ryivhnn, are you using Drupal 7 for these clients you've mentioned? What hosting service are you using?

I don't like to host in China because I'd have to deal with a hosting service that communicates in Mandarin and my Mandarin isn't so good. Getting support with any problems would be that much harder. And getting a .cn domain name requires paperwork and government agencies.

I'll have to play with some ping times and see if I get better response times from Australia or some other neighboring English speaking country. Hmm, ... Hong Kong might fit the bill.

ryivhnn’s picture

I'm using Deasoft. Not all my clients are using D7 yet, I'm in the process of upgrading (one of them has about seventy bazillion modules so may take a while waiting for modules to catch up, they're also pro bono so they get worked on whenever I have time to work on them). The ones that are, aren't complaining. The one in particular I keep mentioning is Western Australian Natural Learning Network, in alpha (the website, not the Drupal version obviously, it's on D7 stable :) and a bit fugly as I threw it at teh interwebz because those "clients" (a group of friends) wanted to start using it asap so they could get away from using the fb group asap. Anyway, they haven't told me it's slow or unusable or not loading, I saw them today and they would have said something if there was a problem as they were excitedly telling all the new people in the group about it today (pressure, now I need to make it GREAT! ;) and I haven't turned on Drupal's built in caching for it yet. I probably should.

I had similar issues with the last provider I had a reseller account with, after 10pm Australian WST all my sites would either go stupid with loading time or just time out. However I couldn't blame D7 as this was happening when all my sites were still D6. So I'm pretty sure it was just the server. The one I'm on now is good.

works at bekandloz | plays at technonaturalist

timonweb’s picture

3-4 seconds to generate a page or to load a page? If to generate (according to Devel module figures) then it's a horrible performance. Your hosting should spend around 1 second, better 0.5 second to generate a page.

lancerkind’s picture

After doing some admin configuration on the site, and I click save, it takes 3-4 seconds to return with a view of the results of the save. (For example, configuring a Feeds importer, setting the configuration, and then clicking save.) This is similar performance as my WordPress site, for creating content, then clicking save. (Hosting in the US, I'm in China.)

Maybe I need to try another hosting service so I have a new perspective.

Mark_L6n’s picture

Is there an effort being made to fix the speed issue with Drupal 7? We're deciding which CMS to use right now, and I was leaning towards Drupal until I installed it and had an empty install performing slowly, when Joomla and WP were not having the same problem. If there's an effort being made to fix the speed issue, I could justify choosing and sticking with Drupal.

lancerkind’s picture

Check if your ISP is throttling your CPU. You may have a dashboard with a "check throttling" button somewhere. That's how I found out what's up. My ISP is only giving me 20%. You could argue that, well, then Drupal is too much a resource hog, or maybe you need up to of 50% resources.

Maybe Drupal spikes the CPU for a short period, but it's defiantly NOT for a long period. It would be better that throttling stay off until after a few moments of resource utilization (moments defined in the SLA) NOT based solely on resource utilization.

So while Drupal 7 does use more resources, I think their is a problem with how throttling is implemented, at least on my provider. (BlueHost) I'm checking with them for alternative plans.

lancerkind’s picture

I need to do some research as I think Drupal 7 and BlueHost isn't going to work out. I knew I was going to move it somewhere else for production, but I'm having trouble at certain times of the day just building my prototype (2-3 minute waits after saving a configuration).

Mark_L6n’s picture

I'm using the HostGator Business Plan.
Right now I just have an empty install and am browsing through the various admin panels, which can take a few seconds to appear. It doesn't make sense to me that an empty install with no other users would run so slowly. It also raises the concern of what will happen with a website once it has hundreds or thousands of users.
The comment of one user is interesting--that maybe admin pages run slowly because of the heavy use of javascript. It is surprising that all of that is in pop-up lightbox-type displays instead of html pages, so perhaps that suggestion has merit.
I haven't found a "check throttling" button yet (plan uses cPanel). There are 'suggestions' to not use more than 25% of CPU cycles or memory.
I wonder if there are adjustments that one can request from a hosting provider to improve 7.0 performance.

lancerkind’s picture

I don't know if all cPanels are the same. Do a ctrl-f find for "throttle"
JavaScript performance is related to your browser. Chrome, Safari, and some versions of firefox are quiet fast. You'll need to investigate this for your version of browser or, as some of the above comments suggest; turn off the panel.

The CPU load that spikes up isn't related to browser speed though.

I feel your concern too ... Scalability to thousands or more users means whether the system stays at a consistent speed. So a scalable system may give you the same speed from 1 to thousands of users.

For me, my problem is hosting. I can't admin a site that slows down to 2-3 min response times, occasionally. So I will not be going to production with BlueHost/Drupal 7.

I've heard good things about HostGator and their commitment to powering their servers with renewable wind energy. I hope they work for you!

yakker’s picture

Talked about in this thread: http://drupal.org/node/1080330

They've filed a bug, and it has to do with database scanning (I think - not technical enough to quite understand it, myself).

I am also on Bluehost, and can confirm that my D7 install gets throttled. What's scary to me is that I'm the only user engaging with it (nobody else knows it exists).

I appreciate all you who have done so much troubleshooting to move this forward - my thanks!

Xandrean’s picture

I'd dare to say that most hosts were running older software as it is a pain to upgrade stuff (usually you have no idea what can break when you upgrade) and now that Drupal changed the default database storage engine those flaws showed themselves. I had a similar problem with D7 but changing some database settings on my server did the trick, but this is trickier when your're not the admin of the server nor have root access.

Search for my posts named Fixed!! innodb_flush_log_at_trx_commit=0 on this page, theres a solution mentioned that worked for me (you will probably have to have access to the database config file thou).

Best of luck,

yakker’s picture

Thanks Marek,

I was looking at those few posts earlier, but I'm not sure how much freedom I'll have to tweak those settings on my cheap hosting ;)

Drupal 7 just might be overkill for what I need anyway - but I liked coding D6 modules so I was just hoping to have a D7 sandbox.

Again, thanks for posting all the work you did investigating this stuff!


bmateus’s picture

Well, I suffer from the same problems described here, independent of the browser.

I use Hostgator.com on a couple of different websites with Drupal 7, and I've been happy with them so far.

But now I'm doing another which has more Content Types, Views and Taxonomy than before, and while it's still just developing (still structuring the website, so I'm using Bartik as a theme for now), I'm starting to get a big performance hit while I'm administering it.

Many times, saving takes 1 - 2 minutes (Views is the worst). But what puzzles me is that this just happens every other time. One save might take 1 second, but another save might take 2 minutes, or even stop (not crash), and then gives me an AJAX message, saying it didn't reach status 4 (the conclusion of an AJAX request).

This might be from server load (strange, as D6 has no problem)? Or maybe some bug?

-- Update --

Just to tell you guys I've cleared some issues by disabling 3 Core Modules: Dashboard, Database Logging, and Update Manager.

I'll run some tests and I'll say something later on, but looks like after all my problems might have to do with too much database information going on...


Bruno Mateus

RumpledElf’s picture

I find its the caching causing the problems.

On a cold start, I get around 350-450 Very Slow Queries - about 200 of those are drupal_write_record and the whole thing takes usually 15-25 seconds - and then next page 138 queries, then 40, then settles back to 37 (39 for anon users - wtf?). Then the site is very fast for a while for all users. Cache expires, you get another 15-25 second page load. And this is after I put APC on - before APC it was running into minutes. If you aren't constantly surfing the site and you come back every few hours to do something adminny, you get the slow cold start more often than not and d7 appears heinously, heinously slow. The clear all caches button takes only slightly longer than a cold start and the slowness of that drives me nuts too.

What I'd love to know is how to stop the cache expiring. D7 would probably perform very well if it kept the cache until you told it not to, ie until you hit the 'clear all caches' button in performance. I know its only one person every so often getting the full cache rebuild, but when you're the one that always gets it it is hair-pullingly frustrating. Not sure if it is a good idea stopping the cache expiring though, right now its just an idea and I haven't investigated it.

shaiss’s picture

Disabling 3 Core Modules: Dashboard, Database Logging and overly did the trick for me. My two sites went from minutes to less than 5 seconds at most for any request. I left update manager on as I want to be able to easily update and install new mods/themes.

inTOOLS’s picture

I also experienced the slow loading of my D7 installations. I had few of them, testing on different hosting providers. I observed that D7 is slow when there is a PHP 5.2.x version on the server. On the PHP 5.3.6 for example D7 is quite fast (of course it can be even faster when you compress CSS and JS, and enable caching). I have a feeling that the version of PHP is the main problem here.

bmateus’s picture

Maybe you have a point here, all my D7 are starting to become more and more slow, and they're all hosted on PHP 5.2.x.

As they are shared hosts, I have no control over the PHP version.
But as soon as I install D6, the websites are very speedy.

Bruno Mateus

inTOOLS’s picture

I do not know whether my previous guess about PHP 5.2 vs 5.3 was correct, but today I played a bit with a section in Drupal's main .htaccess file. This was because I installed D7 on different server, and this one had a problem with encoding (see "Content Encoding Error" in http://drupal.org/node/989634). When I commented the following lines at the bottom of .htaccess for D7.2 the encoding problem was gone, and moreover, the site was fast .

  <IfModule mod_headers.c>
    # Serve gzip compressed CSS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

    # Serve gzip compressed JS files if they exist and the client accepts gzip.
    RewriteCond %{HTTP:Accept-encoding} gzip
    RewriteCond %{REQUEST_FILENAME}\.gz -s
    RewriteRule ^(.*)\.js $1\.js\.gz [QSA]
    # Serve correct content types, and prevent mod_deflate double gzip.
    RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
    RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # Serve correct encoding type.
      Header append Content-Encoding gzip
      # Force proxies to cache gzipped & non-gzipped css/js files separately.
      Header append Vary Accept-Encoding

Then I switched to other server with PHP 5.3.6, on which my D7.2 was loading very slow at the beginning, and did the same (commented above). The site is fast. Of course, as in the first post Overlay and Toolbar slow it down when you are in the admin mode. But anyway, this is something which you can live with.

bmateus’s picture

This could be because you had another caching system installed also?
I've been told that you always should choose one or the other, never both.

Sometimes run-time compression and external caching don't go well together, as the web server's cpu becomes bogged down trying to compress a lot of files. And Drupal has a lot of files to process...

Didn't work in my shared hosts, tough. They don't support run-time compression.
Nice to know, tough.

I guess that, these days, it's more about the server's speed than bandwidth speed.
Because broadband became cheap, everyone has broadband. But not everyone has big and fast webservers. That's not cheap...


Bruno Mateus

inTOOLS’s picture

I think that you are right about the webserver performance which has huge influence on how fast the web page is served to the user.

Today however I checked a new idea: cron scheduled tasks. On my D7.2 installation, the cron was scheduled to run every 3 hours. Unlike in D6, now, in D7, cron jobs are invoked by the browser request using so called Poormanscron module (http://drupal.org/project/poormanscron). The cron jobs run on the server, and sometimes, when your server is not very efficient, it takes a few seconds. During that time the user browser waits for the rendered page. I am testing it right now, and changed cron jobs to run once a week (in admin/config/system/cron) on the sites which I am just building. I think that this will help, because it agrees with my previous observations. My sites were sometimes fast, and sometimes extremely slow at first request, and then later requests were served fast again. Not on every server though, that is why I made a guess about PHP issue or compression issue, which also can have some influence.

wstein’s picture

PoorMansCron shouldn't make loading a drupal page any slower...
This is because PoorMansCron waits until the visitor's page has loaded, then waits a random amount of more time, and (if cron is due to run) THEN it makes an ajax request to the server which causes the server to process all cron jobs.
So, if you (or someone else) leave one window open to your website all the time, the javascript poormanscron should periodically cause cron to run on your server. This does, of course, make the server process the cron jobs, which might make the server slower while the job is running.

jpanigrahi’s picture

This forum is really very key to addressing performance issue in our respective D7 env. My local D7.2 install performance is good enough to continue my development. My scenarios and observations are like this...
- I first installed D7 fresh in my windows laptop using microsoft web metrix. I installed and activated quite a few modules on top of Core and performance was not an issue.
- I then switch to the latest D7.2 version, but did a new install using xampp tool on WAMP stack. I again activated quite a few modules on top of Core and performance was not an issue again. My other drupal instance on MSSQL/IIS was still active, but was not running at the same time though.
- During one of the module upgrade to latest version (imce-7.x-1.4 from 7.x-1.3 version), I encountered "Fatal error: Maximum execution time of 30 seconds exceeded [in some files]" error and may other operations as well. Then I set max_execution_time to 300 from 30 and memory_limit to 512M from 128M in php.ini file. The error went off, but my D7.2 site became very very slow. Page rendering went up from 5 secs to 1 min, All Admin functions like click on Module Tab went up from 10 secs to 3 mins.
- I then landed up on this forum and disabled quite a few Modules like 'Update Manager' Dashboard' Devel' and most of the modules listed in this forum as well turned off some performance/logging/cron actions. No avail, still performance was really bad, you can not do any admin job or configurations.
- Then I noticed, even if I am not seeing '"Fatal error: Maximum execution time of 30 seconds exceeded" error, my 'imce' module was not listed in the module list. Before I was getting this error, the imce 7.x-1.3 version was there and was activated as well.
- I decided to re-install the imce 7.x-1.4 afresh from Module menu, installed and activated it successfully. Magic happened , the Performance of my D7.2 became normal and back to original level and No Issue at all. Since then I am using it heavily and Performance is not an issue, all clicks usually are performed at few secs.

My point is, I think when some modules are getting installed or upgraded (same may happen when some one upgrading their Drupal instance) and if it fails with out completing the process, Drupal is leaving something in the system that is causing this heavy performance bottlenck. My suggestion , for this kind of performance issue, re-vist your modules (those were already there in the system earlier and now not present) and try re-install those again successfully.

Hope it may help some of you. thanks

megan_m’s picture

Excellent tip, Jasob! For me, uninstalling and re-installing CKeditor and IMCE seems to have done the trick. I encountered these problems after migrating a site to another server.

Woolwich Web Works: Custom web development

danieljulia’s picture

I had the same problem, terrible performance on my 7.7 installation, and no IMCE or CK editors installed.
I tried to call update.php and it seems doing the trick, although no significant message after calling update appeared

hope it helps, and this bug is being fixed in next release

n1ckyb0y’s picture

A site I was working on was very slow when loading the home page.

I found after actually 'uninstalling (not just disabling)' Update Manager, the performance was much better and faster. There was no lag when loading pages.

But now I don't have Update manager installed.

sachbearbeiter’s picture


sneakerr’s picture

This with turning of some of the modules like overlay or toolbar worked for me pretty well. Using Caches is the solution to use on front end and does fix the speed problem for anonymous users.

Brackish Lake’s picture

I hate to say it, but I think D7 was a step back in a lot of ways (and a step forward in other, valuable ways). Even with a core install, it is painfully slow - at least in terms of backend administration. D6 felt fit and efficient; D7 feels like a fat old dog when developing.

no longer here 1724396’s picture

Not only is D7 slow, it does not scale.

Runtime scripting languages (like Ruby, Groovy, Python, PHP) simply are unable to compete with their strongly typed counterparts (like Scala, Java, C#) in terms of speed and scalability. Twitter canned Rails, plain and simple, too dog slow; they are now a Scala shop with legacy portions of their infrastructure in Rails.

I spent 10 years doing LAMP stack devel, hacking away in the lovely mess that is PHP ;-) PHP is a great quick & dirty web language. Drupal is based on said quick & dirty language and reaps the "rewards" of that choice made by Dries over a decade ago. On the one hand, PHP is easy to learn and therefore makes Drupal adoption larger than it might otherwise be (e.g. if it were written in Ruby or Python); on the other, it's slow and painful (at the code level) to work with.

BTW, this is not a Drupal bash, I absolutely wish it was cloned in other langs in the same way that Rails has been. D7 admin is a thing of beauty, not to mention the complete out-of-the-box experience that one gets post-install: you immediately hit the ground running. The same cannot be said about Rails, for example.

Now, it has been asked before, why not write Drupal in another language? Well, would it make that much of a difference? Drupal is by and large a database driven system, which is to say, at runtime the majority of configuration is determined and processed. Yes, there would be speed and scalability improvements, but nothing like moving from Rails to a custom Scala solution, as Rails (brilliant also, BTW) conventions are code driven (RESTful routing, controller, model, etc.) as opposed to database driven. Long & short, Drupal relies heavily on the DB layer and is therefore slowed by that aspect alone, regardless of the language it's written in.

OK, rant over ;-)

bmateus’s picture

So the solution has to pass through a quicker DB system, according to your theory.
I'll "buy" that, makes sense to me.

Bruno Mateus

dan.hu’s picture

I'd been having the same problem. And with me, it was not Update Manager that caused it.
I disabled some modules, including Toolbar, Contextual Links, Update Manager and etc. at a time. It got much faster. And it didn't get any slower after I reenabled Update Manager. It was most likely to be Toolbar or Contextual Links that made Drupal slow. But I'm not sure which one that really did.

MLSatya’s picture

I have also disabled the dev mods, toolbar, overlay and update manager. It seems to have sped up.
But again, clients could care less about under the hood. They want a zipping site.

Any other ideas are much appreciated thanks

recent sites with D7:

Asogan’s picture

I'm no expert but I initially tried XAMPP with Drupal 7 - painfully slow.

I then used the Acquia Development install, which is an 'all in one' install (includes AMP). It's hitting lightspeed compared to my previous experience. Install was much, much easier too.