I have a site I am investigating that has major performance issues, using memcache I was able to bring number of queries down both in number and total exectution time ( from 3 secs to 230 ms) but the page execution time is eluding me ( I am looking at values outputted by devel) my understanding is that page execution time = time taken for php to execute therefore I installed APC and I can see php opcode being cached and stats showing hits in APC control panel ( apc.php shipped with APC ) but my page execution time does not go down. So I think my question is two-fold:

  • What all contributes to ( better slows down) page execution time? Is it just time taken to execute php?
  • What approaches should I take to bring down page execution time. I tried APC but not much help

P.S number of modules used on this site is just enormous ( 168 ) but right now I am not in a position to make that recommendation, its more like a fire in the hole situation.

Edit: Output of running xhprof on local instance (recommended by mikeytown), this seems to be crazy I think the later results are due to thrashing? diff runs for the same url have drastic difference and its just too much resource usage. Also not sure why is it showing values which are not from today :| (I just installed xhprof on this laptop)

Output of running xhprof on local instance

2 Answers 2


Get a cachegrind of your site. xdebug or xhprof can generate one. This will tell you what functions are taking the longest to run. Until you do this, its a bad guessing game.

  • Hey, thanks for the suggestion I just ran xhprof on my local development version (laptop not on server) and I see this - picasaweb.google.com/lh/photo/… Is this for real? I mean is it even possible for a page to consume 750Mb of memory?
    – Dipen
    Commented Mar 18, 2011 at 21:12
  • Could it be coz of thrashing? the later profiled data for the same url, if u look at the bottom same url takes much less resources but a diff run shows completely diff and extreme resource utilization.
    – Dipen
    Commented Mar 18, 2011 at 21:15
  • 1
    It really depends, but for 99.9% of setups if your using over 100MB of ram something is wrong.
    – mikeytown2
    Commented Mar 18, 2011 at 21:16
  • Other than the number of modules, could there be anything else wrong? I am not sure if modules can be removed from production right away. Btw, on local I am using nginx + php-fpm and on production the site is using lighspeed with fast cgi.
    – Dipen
    Commented Mar 18, 2011 at 21:27
  • 1
    You need to drill down into the cachegrind and list out what function are eating up all your time. img715.imageshack.us/i/cgrindout.png
    – mikeytown2
    Commented Mar 18, 2011 at 22:54

EDIT: I misread the original post. 168 modules is a lot, and 300 to 700ms of SQL queries is huge. The more modules you will use, the more queries they will be as soon as modules does some.

Use aggressive caching while you can, cache everything, if it's not enough, try a reverse proxy cache. Using a CDN for files can greatly improve the whole thing. A reverse proxy cache can also help you by removing some auth cookies when hitting pages that does not needs it (then core will think user is anonymous for those and maximise caching).

The Drupal core dynamism make the whole dawn slow as soon as you have too many modules interacting at the same time.

I'd say, for example, if you use a lot of modules that loads data at hook_node_load() time instead of using fields, it will make a lot of queries while the field usage would have ensure caching efficiency.

Rendering can take a lot of time also, drupal_render() (the rendering API sometime being called) is a nice piece of API (really useful) but also a bit slow. Switching to PDO (D7) and the full DBTNG (which is great by the way) also add non neglictable latency.

That said, core by itself is quite fast (but it does too much SQL queries, even with almost nothing installed), poorly coded modules often are the bottleneck.

APC can divide execution time per 2 or 3, depending on the code that runs. if you configure it well (enable all APC optimizations, the offical APC manual is well written and will guide you).

If you are on a box with a slow file system (network file system or slow hard drive) it can imply a visible impact on execution time. Drupal is made from a lot of small files, which forces PHP to do I/O on the FS each time it loads one of them (APC also helps a lot for that).

A misconfigured DBMS can also be quite an ugly bottleneck, if you are using MySQL think about doing fine tuning. If you are on a shared hosting, if it's not Drupal specific (or ready) DBMS and PHP stack will probably be misconfigured or non-tuned, which can lead to really slow sites.

Don't forget to activate all the caches. If your site is not authenticated user oriented, then activate the aggresive page caching (it really is amazing).

The more you'll have blocks, the more full pages will be slow, Views' module blocks will be a dawn bottleneck (depending on the Views plugins you use, OG's block can be a real pain) if you don't restrict their visibility on a per-page basis, or with custom PHP code (any other block also, always set your block visibility manually, greatly helps the framework by avoiding it to attempt to render empty blocks).

Avoid modules that uses hook_init(), hook_init() is being run on every page, even if you get a 403 or a 404, which slows down everything (it even slow down imagecache|style generation time, and 404 errors on files would be dawn slow just to tell you the file doesn't exist).

  • Hi, here when I say page execution time I mean the value that is shown by the devel module at the bottom of the page and not using it in the general sense of drupal request/response cycle which also includes SQL queries etc. My question is in context of authenticated user. So when devel reports page execution time does it also include sql queries?
    – Dipen
    Commented Mar 18, 2011 at 18:48
  • I am not sure if filesystem would be a bottleneck as I am on 15k RPM linux filesystem. SQL queries are taking roughly around 300-700ms depending on the page but page execution time ~= 3 sec (reported by devel). Not sure what else could be the problem.
    – Dipen
    Commented Mar 18, 2011 at 18:49
  • Oh sorry, I misread your original post. Devel value is computed from boot to shutdown (devel module has it own PHP shutdown handler for doing a lot of stuff including this). I'm not sure exactly when it starts and stops, but pretty much the whole Drupal page build time and business specifics are included in that page execution time. Yes, it includes everything (including SQL query time and latency), and its own latency (devel query logging has a performance impact also).
    – Pierre
    Commented Mar 18, 2011 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.