One of the great things about Drupal is the wealth of code you can leverage for your projects. There are thousands of modules you can use to build your website on. The downside to Drupal is there are thousands of modules you can use.
I have been slinging code since the early days of 6502 assembly and in those days memory was very expensive. So we had to write our code as efficiently as possible. This carried over to my C++ days and then came the web. In the early days of web development, bandwidth was the constraining factor. Images that were too large took forever to download. We often provided lower resolutions of an image and used the LOWSRC attribute of the image tag to tell the browser which image to present while the real image downloads. All our images were heavily optimised to squeeze every ounce of performance out of our web page.
Then bandwidth issues went away… people had broadband and the new batch of developers didn’t have the same constraints as the old school of developers. You could now embed video and higher resolution images and make them available across high speed internet connections. Websites became faster, more complex and web became richer as a result.
Now here’s my problem.
When you build a site, do you think about what happens to the poor webserver when you throw 20,000 users at it? Have you sent emails to your customers and watched the traffic come in and your server make a coughing sound before melting into a pile of integrated circuits and shame. What happened?
The more complex your site becomes, the more workload it puts on the webserver and that workload is then compounded as more and more users come onto the site. So when you send out that email and get that heavy rush of traffic, it’s often too much for the server and your site can become unresponsive or worse, go offline.
So how does this tale of horror relate to Drupal?
A lot of users who come to the coffee club often want to debug their performance issues and 9 times out of 10 there is just a plethora of modules installed. No wonder your site runs slow! Your site is bloated with too many modules. Each module you install increases the PHP memory required to run that process, more modules = more memory. Drupal runs incredibly fast out of the box and with a little thought and some self control, you can vastly improve the performance of your website.
When you start to look at large scale deployments, we go back to the old ways of shaving every ounce of performance out of our application. Combining images into a sprite, offloading assets to a CDN, reducing the number of database calls per page and reducing module counts. Here’s some questions for you, if you answer yes to any, you may have too many modules enabled.
- Do you run the admin menu on your production site?
- The devel module?
- Views UI?
- Imagecache UI?
- Context UI?
- Rule UI?
- Node Clone?
- Content Copy?
- Views Exporter?
The problem is that having the module or feature enabled, your php process size increases. Do you really need panels if it’s only used on one page of your site? Couldn’t you do the same thing with layout CSS and simple coding?
By reducing your module count, you reduce your memory footprint and the number of database calls on page load. When you throw a number of users into the mix, the server will be better equipped to handle the workload.
Why not take a more Zen approach to your Drupal developmet? When you come down to choosing your modules, try meditating on these Mantras...
Ohhhhmm, Do I really need this module in my application?
Ohhhhmm, Does this need to be enabled on my production box or only on my dev server?
Ohhhhmm, Could I do this in my theme?
Ohhhhmm, I don’t need this UI in my life… (repeat until you reach Drupal Enlightenment)
My personal website runs a total of 4 modules, as I look at adding more functionality, I evaluate the need to install any new modules, do I really need it? Is this an opportunity to find out how to accomplish the task using more native Drupal methods?
My needs on my personal site are minimalist compared to most large scale deployments, but the philosophy should be the same for both.
Always remember, Less is more… (now chant - oh mani “performance” hum)
Additional Resources:
Free Drupal Whitepaper | The Mobile Web and Drupal
Going Mobile with Drupal | Mediacurrent Blog Post
Responsive Design + Drupal | Mediacurrent Blog Post