My concerns about Drupal 7. Drupal became even more slower and this is bad for its future.

Agreed here. Used D6 and it worked fine, speed was very good and I loved it. Installed D7 now and am horrified. I hope it's just me and my database/server having something configured badly, but at this state the thing is unusable. Will have to test it on another machine and see how it goes there.

Interesting, for all the drupal 7 hip hollering and party celebrations, it sure is awful quite on the web regarding Drupal 7. I can't find anyone talking about it not even on drupal website. I realize it's still new but the hype was so big I thought for sure everyone would be installing and upgrading.

I tried to upgrade from drupal 6 and it was a complete failure. I ended up having to install it from scratch. I am not impressed with Drupal 7, three years and that's all they came up with ?

I also upgraded wordpress and it took all but a few seconds and everything was updated. Wow and it took drupal three years for drupal 7, now they must already be working on drupal 8 lol

I've been seriously considering going to wordpress, it's become a powerful CMS and I think in many ways is light years ahead of drupal. While drupal becomes more complexed, wordpress is getting easier and more powerful. I don't think it will be too long before wordpress gets it, they are already getting it.

I love drupal but seriously 3 years in the making and this is all they came up with. A big disappointment.

Sorry, everything is loading almost instantly for me. The first view might have lagged slightly, and I probably only think that because I was looking specifically for performance issues. Have you fixed it or do you have one of those annoying hosts that oversell or that have weird ways of handling peak periods? I switched host recently due to suspecting aforementioned problems as my sites would run fine except past 10pm Australian WST where they would become unusable if they loaded at all.

technonaturalist was built on D7 alpha and I haven't noticed any performance issues all the way through. It's not as module heavy as my community siite which I haven't upgraded yet, but there are a few on there.

Some numbers.

On IIS / PHP 5.3 (fastcgi autoscales) + wincache 2 with vanilla D6 and D7 with devel generated content, both on InnoDB I get the following results:

Without page cache enabled on the frontpage:

D6: 73 requests/s (10-50 concurrent users) 
D7: 45 requests/s (10-50 concurrent users)

In D7 a lot of time is spend rendering the page array.

With page cache enabled on the frontpage:

D6: 469 requests/s (50 concurrent users, lower with 10 concurrent users)
D7: 377 requests/s (50 concurrent users, lower with 10 concurrent users)

Here, it's D7s bootstrap that takes > 2x more time than D6 (28 ms vs. 13 ms)

edit: updated numbers for tests ran without the xdebug extension enabled.
edit: protip: if you get only a few requests/second on a Windows host with a localhost database, use 127.0.0.1 instead of localhost in settings.php or PHP will throw a fit (timeout) on an IPv6 connection attempt.

Is this a classical case of: 'OO as efficiency killer'?

I agree with the OP, D7 is unusable slow in its current state. Unless you've got the money for a dedicated server and a specialized setup it makes no sense to use D7.

Looks like Drupal 7 is a Windows Vista.
Hopefully Drupal 8 will be a Windows 7!

In my opinion, and this is after 5 years on drupal, D7 is a mis-step. It's been made far too heavy and far too slow...in short, too many API alterations/additions and frills/bells on top of that. Just need to look at the download size of the last three versions:

D5 - 750kb
D6 - 1.05mb
D7 - 2.6mb

wow!

Someone mentioned the lack of "buzz" on the internet with this launch and that's something that has staggered me. It's almost as if it was out of the gate and then covered up. What happened? Is it the (as of writing) 4 criticals and 209 major bugs? That major figure was about 120 ten days ago. Was it released both too late (promised at the end of 2009 initially) and too soon at the same time???

I already have one client who has decided to jump from D6 to D8 with the hope that "they sort out all the crap".

This sounds discouraging. But lets not throw our hands up in frustration and declare Drupal 7 a right-off based on performance. The rest of the community still needs to catch up, this is a collective effort.

I installed d7 RC3 on my local machine to try it out for a new project I've been working on, thinking to convert it to d7.

The original site (just the page itself) loaded at 30ms according to YSlow and 1002 on D7. In the admin section, the overlay stalled it so badly I turned it off.

I'm going to use d7 on another site I have (the cliched d5->d7 upgrade) that is basically just static so the caching can take care of things, but after that experience I am *extremely* reluctant to use d7 for anything else at this point.

It may be that D7 is slower than D6.
But when you don't use the opportunities to increase the performance (eg. apc, cache-system, and so on) then D6 is also too slow to work with it.

And you don't need always a dedicated server to use e.g. an opcode-cache.

I have a small webhosting-paket by hetzner (4,90 Euro per month) with the possibility to enable eAccelerator and then D6 and D7 have a good performance.

My site on GoDaddy shared hosting plan is also experiencing major performance issue after installing Drupal7. It's taking around 3 seconds or more to load a simple page. I had a problem upgrading from D6 so I end up clean installing D7. I love the new layout in control panel but the slowness is a killer.

I think OP is right about the Google using page loading time as a ranking factor. My site ranking went down a bit after installing D7. There was no change in site content. I hope there is a service pack come out soon to fix this performance issue.

A VPS from Linode is anything but expensive. At 19.99 or so a month, a VPS from Linode is barely more than an MMORPG subscription fees (and some of these games sport 12mil users indicating that a large portion of the population can indeed foot that price on a monthly bais).

While I agree that a CMS should be able to support the lowest common denominator (shared users), I don't think it should necessarily come at a cost to those on real servers. Perhaps drupal7 should have a thin/light install with some key features simply disabled.

I do agree that 7 is slower but overall not terribly. I also have to strongly agree that there is NO buzz whatsoever in comparison to the release of Joomla! 1.6 or compared to the buzz there was when WordPress 3 was released. Not that there needs to be for me to use it, but I almost feel like not telling any client what the underlying framework is (only reason to do so is so they can do their own research). Questions will always be raised: why not WordPress or Joomla?

Programming-wise, the thing that Joomla and others have at minimum is an MVC implementation which simplifies DB access greatly (although at the moment Joomla only supports MySQL/MySQLi). Same goes for Magento (except EAV-style database transactions), using an (very complicated) extension on the Zend Engine. Regardless, on either, I cannot easily have a syntax error in SQL (like in 6) nor am I even 'knowing' it is a DB hit (like in the case of 7). The same patterns exist in other languages. Django and others are beyond this in automatically creating a schema based on your model (your class).

The Field API is CLOSE to this sort of thing. At least with that you are not overly concerned with getting the right table name. Accessing the database directly should be highly discouraged and similar should really be given as model to support good programming practices.

The whole point is to get rid of the mundane (like having to create a schema (hook_schema()) and then memorise it to quickly program for it), which should be in core by now. Writing db_select()-> instead of the full query in a string is hardly any better and hardly a solution. The real problem is the programming interface in core is still making us programmers take more time to do mundane things that core should do on its own (like creating a schema, setting up a customisable administration page, storing variables, etc).

7 is indeed a fix-up on 6 and adds some nice new features and fixes some previous annoyances (AHAH in 6). However, a Drupal 7 site out of the box is still far behind what WordPress has (a built-in WYSIWYG editor) and Joomla! (an example content-rich homepage set to default). In terms of getting users, a Welcome screen is just not going to work.

With Joomla! finally getting a forms API and a ACLs, it seems like Drupal is going to lag behind. I'm always researching new things. Many others in 'Drupal-land' are extremely biased and think Drupal will do anything reliably and speedy. Realistically, this is NOT the case.

The practical implementation of D7 has bee http://www.drupalgardens.com and except for the first time loading that takes few seconds more than normal pages, which is well within tolerance limit, I didnt find D7 to be any slow.
It might be the problem with system configurations for those who found it to be slower.
There are some limitations to shared hosting - agreed. But it will take some time to address such issues.
Thanks that you people have put this topic so that the developers will look into it. But if we dont configure the basic settings that are way different for various platforms and change from application to application, we cant simply blame this inability of ours onto the software that is relied upon by millions.

I have a D7 blog on shared hosting at Siteground and i haven't thought for a second it was performing slowly. D7 is awesome.

I'm building a simple photo gallery / showcase site for my sister, a semi-pro photographer. Just for fun, I built the same functionality into two builds, one D6 and the other D7. Both are on shared hosting, because I don't expect her site to blow up out of control. No special caching/optimization systems, other than Drupal's own.

Without any content except for a couple test nodes, D7 is noticeably slower to load anything: front page, sample photo page (same photo/text on both), featured photos page (a simple View), etc etc. Mind you, I built them in parallel, starting from clean installs. And the D7 version has far fewer modules installed -- but then a bunch of stuff made it into core.

I didn't run any scientific tests or compare the logs or anything, because if I can see it with naked eyes, I don't need to see any logs to know that's a pretty big difference. I thought I was just trippin out until I began Googling and saw this and other threads.

Despite the difference, though, I'm going with the D7 site, and will polish it up before handing it off to my sister (the Client). Why? Because it's prettier, and it's easier to use, and my not-so-tech-savvy sister will have a better time using it. For her and for many other folks like her, I believe the ease of use is more important than lightning fast load speeds. They don't even know what load speeds are. And guess what, when and if my sister's portfolio begins getting mad traffic, I'll migrate the site to a proper server, and by then her hobby will easily cover the increased hosting costs.

Worried Google is pushing your rankings down? Egads, spend a couple bucks on better hosting. You gotta spend money to make money sometimes, and business people will understand that point if the developer explains it clearly. I've never had trouble convincing the client of this fact when necessary, and Drupal has too many other benefits over Wordpress for this to be a deal breaker.

I think D7 is going in the right direction, personally, and also I have no doubt the leadership and community together will eventually fix the existing issues.

---

In the end, though, I'm super biased, because I'm pretty much a Drupal groupie. I've been using it since 4.7, and professionally since 5.x something, I forget. I don't touch Wordpress unless clients specifically ask for it. Joomla? Expression Engine? Please.........

I also agree with ColdSun that "Drupal is a framework that works as an out of the box CMS, not the other way around." Well put.

I've installed D7 on my local XAMPP and a fast dedicated Server and on both on them it run not really fast. (It should, both have at least a Quadcore!) So I stumbled upon this thread.

Well, I've solved my Performance Issues and the Problem for me was a very insane Standard Webserver Config.
It seems that MySQL comes with a config preset that is optimized for Webservers with 64-128MB RAM. And InnoDB doesn't start at all, if I tried to it wouldn't work. But still, InnoDB Tables work, but are incredible slow.

So my solution to this Problem was that I optimized my.cnf a bit (but couldn't activate InnoDB sadly). And I converted all my InnoDB Tables to MyISAM which seems to be more forgiving with bad configuration. (HeidiSQL is a great tool for things like that)
What happend was a Performance-Boost that I didn't expect:

Before a D7 Site took an average 3 secs to load, Admin Sites about 5-80 seconds.
After those config changes a normal site loads in 150-300ms and even complex Admin Sites within a few secs, sometimes less than a sec!
Devel Performance Logging showed me that some queries (especially for the cache tables) run after conversion to MyISAM about 100(!) times faster.

Also I've installed APC but this didn't matter very much anymore. (Didn't change much)

So now I have a LIGHTNING fast Drupal7 install.

So maybe some PPL have this Problem: Drupal6 uses MyISAM by default so you won't get much performance issues with bad(=standard) Webserver Configuration. Drupal7 expects a more modern Webserver (which is a good thing!) and if your Webserver doesn't meet sane Configs the Performance will be very bad.

I hope this is helping some Folks out here ;)
Simon

Hello all

I BELEAVE DRUPAL SHOULD ALSO HAVE A QUICKER TEAM as it has a SECURITY TEAM! This team should have only one task - "is this function really necessary?" how it influence the drupal processing time....

I have read your posts and for the first time I take a look to Wordpress.... THAN I HAVE FOUND a solution to make my DRUPAL 7 Faster - I HAVE DISABLED ALL MODULES! (or almost all). Please try it! In fact I haven't disabled block, menu and user which I really need. (Now I have a drupal framework which is almost as quickly as wordpress... almost)

I have written an issue to drupal7-dev in which I asked core developers to try solutions to make modules lighter and to have modules with a lot of sub-modules to leave us the possibility to enable only what we want ... the issue was closed (won't fix) drupal.org/node/1435594 and moved to drupal8-dev, but I was encouraged to get involved with the Drupal 8 development... I really need a quicker drupal7 until drupal8....

What should I say: I'm not so confident I'm good enough for that but I'll try. I'm also encouraging all of you who want a quicker drupal to look at drupal files. I'm confident that a lot of tasks can be optimised in drupal7!

FOR EXAMPLE: I have looked on how drupal7 manage blocked IP addresses.... a lot of variables and constants are declared before, at least 2 functions etc. In my opinion that should be a very simple task: include settings.php, verify user ip (ip_address()) and compare it with some values in settings.php (I think database solution should be eliminated in order to make drupal quicker) and THEN define DRUPAL_ROOT, include bootstrap and so on.... You may also look at drupal_block_denied function... why it use check_plain and ip_address()? Are these functions really necessary? I'm sure NOT! We can write "Sorry your IP is banned!".

Of course my observation is not so important for drupal7 speed (but it will give us some ms less processing time), but this example point on some aspect: a lot of functions are used even they are not necessary! .... so drupal is slower that it can be!

PLEASE VOTE WITH ME FOR A DRUPAL QUICKER TEAM! I don't know much about how SECURITY TEAM works but I'm confident we need a DRUPAL QUICKER TEAM!

Thank you for your time!

Interestingly enough, I found this thread while searching on Google for:

Drupal 7 slow loading first time

I've really been struggling with the performance of Drupal 7 and I knew that my knowledge would probably not be good enough to install and get working memcached or Authcache. However, I do have my own VPS (at servint.net) though and I can justify the cost every month by hosting some client sites which works out really well.

I have been researching and studying the performance issues associated with Drupal 7 immensely and found some solutions that were not too hard to implement. To start, I had my web host install APC on my server and then I installed the Drupal 7 APC module. It was as easy as enabling it and putting in a few lines of code in settings.php. I also am using File Cache, Boost and Entity Cache. Those are all pretty easy to get going too. In addition, I have set my Views to be cached.

Once this was done, I fired up Google Speed Tracer and was really impressed with the results. They have a nice video that says users generally start to get impatient with page load after 100 milliseconds and for the most part my backend and front end while logged in was pretty good and well within tolerances whereas before I did all this, it was not. I know all this seems like overkill and it did take me several days to figure out a lot of this but now I can implement on future sites without having to do all the research, it's in my tool kit so to speak.

So the bottom line is, after all this I really have noticed a nice speed gain with a particular Drupal 7 site I am developing right now. It's a multi-lingual / responsive style design site so it uses a lot of resources. Note with Boost in particular and non logged in users (which is usually the case for the type of sites I tend to develop) my pages load in a split second. I highly encourage checking out Boost, it's actually easier to configure in Drupal 7 then it was in 6, far less bloated IMO.

Drupal need to change / expand database choices. MySQL for me is too slow, if you have a lot of multiple queries going on, especially multi table queries. I really hoped that Drupal 8 they have a DB option where it will include NoSQL DB as well.