performance

Drupal Core, a much forgotten API

Let's start with a little Jeoporday quiz!

Answer: There's a module for that, just look it up on d.o.
Question: How can I get this functionality on my website ?

More and more posts on the web are showing up with 'The top x modules you should always install', someone else even created a website for the answer. It's hard to keep up with the new releases everyday, it's sometimes even harder to find out the exact use case why a new module even gets released - although I respect the author because he's contributing, don't get me wrong on that one.

The selection criteria

There are many reasons to pick a module:

  • Deadlines: the functionality is there and the project has to be delivered on time.
  • Workflow: development teams try to work as uniform as possible on every project.
  • Lazyness: why bother writing a functionality yourself (even it you only need one function from a giant module).
  • Strong API: it helps the developer in custom modules or in deployment strategies.
  • PM has found it on the web. I'm dead serious on this one. I've had cases where I had to start on a site where I got the modules picked for me, without even consulting me.

There are other reasons obviously, but what strikes me is that from experience (I'm guilty too) and from a lot of discussions with all kinds of people (developers, project managers, etc), the gap between what the developer needs and the client actually wants has become bigger and bigger. I'm not sure why this is exactly happening, but it can have serious consequences when going live with a project.

The kitten paradox

The Drupal world has this paradigm that you shouldn't hack Drupal core or God kills a kitten. Even worse, Dries too nowadays. This somehow extends to Contrib too, since well, everytime you need to update, you'll have to make sure you have your patches ready. But what about this: every time you're using more than a 100 modules, mankind has killed a lot of kittens by having to install additional load balancers, reverse proxies, web and database servers for keeping the site up if it's a really busy one, especially with authenticated users. Adding hardware because the site is not performing well is - in a lot of cases - not the right answer.

Back to basics

Every project is unique and building a big project should really be evaluated before and - even more important - during the development process, with great care on how the site behaves in a real life situation, investigating the amount of queries, PHP memory, generation time and so on. That's not something you can do at the end. It's simply too late at that point and a lot of kittens have died already. There are great profiling tools in Devel and Xdebug should be your friend all the time. Be sure to use them all the time.

So, depending on the needs, it might be more interesting to write a simple custom module and write PHP yourself again, using either PHP or API functions available in Drupal core. Every developer should've least opened up the includes folder and scanned every file in it. I'm still amazed now and then, even after all those years. Even with Drupal 7 almost out, a lot of people seem scared because Contrib is not entirely ready yet. That's a pity, because there is some amazing stuff under the hood and you'd be pretty surprised how much you can pull off with only Drupal core, PHP and - especially - a lot of developing fun.

Answer: That should be api.drupal.org and php.net.
Question: Which bookmarks should I really have ?

Benchmarks for the Display Suite module

I've been promising benchmarks for the Display Suite module after every presentation I gave so far. It took me a while to get a good setup but now it's here. I've used the demo site as a start, so there are a lot of modules enabled for this test. Views, panels, fivestar, heartbeat, comment, taxonomy, location, gmap, imagecache are the most important ones since they all integrate with the ecosphere of Display Suite modules. I added a new content type called 'benchmark' and added 14 CCK fields to it: 4 textfields, 4 textareas, 2 images, 2 filefields, 1 node reference and 1 user reference. It also has a title, body, 2 taxonomy fields, a fivestar widget and a couple of comments. Depending on the test, the complete set of modules integrating with Display suite are enabled or disabled. These include ds, ds_ui, cd, hds, nd, nd_cck, nd_search, nd_fivestar, nd_location, nd_switch_bm, ucd, ud and vd. You gotta love small project names right ?

Desktop

The first test was ran on my Fedora Core 13 desktop - Intel Core Quad, 2 GHz, 2MB RAM with php 5.2.13 and eAccelerator - ab sending 100 requests with 5 concurrent users on a single node and page caching disabled.

 Without Display Suite
PHP 4.91 MB
Requests per second: 36.18 [#/sec] (mean)
Time per request: 138.202 [ms] (mean)
Time per request: 27.640 [ms] (mean, across all concurrent requests)
 Build mode blocked
PHP 5.31 MB
Requests per second: 34.68 [#/sec] (mean)
Time per request: 144.174 [ms] (mean)
Time per request: 28.835 [ms] (mean, across all concurrent requests)
 With Display Suite
PHP 5.33 MB
Requests per second: 34.51 [#/sec] (mean)
Time per request: 144.876 [ms] (mean)
Time per request: 28.975 [ms]
(mean, across all concurrent requests)

Server

The second test was ran on a CentOS 5.3 - 2 x Intel Core Quad, 2,6 GHz, 8MB RAM with php 5.2.11 and eAccelerator - ab sending 100 requests from my pc to the external server with 5 concurrent users on a single node and page caching disabled.

 Without Display Suite
PHP 4.25 MB
Requests per second: 26.91 [#/sec] (mean)
Time per request: 185.775 [ms] (mean)
Time per request: 37.155 [ms] (mean, across all concurrent requests)
 Build mode blocked
PHP 4.61 MB
Requests per second: 26.76 [#/sec] (mean)
Time per request: 187.072 [ms] (mean)
Time per request: 37.514 [ms] (mean, across all concurrent requests)
 With Display Suite
PHP 4.63 MB
Requests per second: 26.65 [#/sec] (mean)
Time per request: 187.642 [ms] (mean)
Time per request: 37.828 [ms] (mean, across all concurrent requests))
I knew that enabling modules would cause the memory of PHP to grow on both my desktop and the server. The server however behaves better in terms of keeping the requests per second steady per setup, so that's the real good news. I'll probably run some more in the future to see how it behaves in other situations, but I'm glad that I've got some results to show! You may lose a few microseconds, but win days of maintainability!

Subscribe to RSS - performance

You are here