By vjuhasz on
Hi,
Although Drupal is a very powerful beast, the core modules still lack quite a lot of functionality and customization which can be easily handled by the additional modules, add-ons. I know this also adds some increased load to the hosting server, so there is a borderline between shared and/or dedicated hosting.
I would be curious curious how many additional modules do you use on your site in the /yoursite/modules directory, and what type of hosting do you have (shared or dedicated). Any feedback from live sites would be really appreciated.
Thanks, Val
Comments
=-=
The amount of modules depends on the site being built. Most sites begin on shared hosting, then if necessary are moved to Dedicated if the need arises.
Well...
All of my live sites are on shared hosting. The site with the fewest modules has only one module (codefilter). The site with the most has 23. I am designing a site that will have several more.
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
go ahead and use lots of modules, just cache like crazy
There's a lot of variables including traffic, type of modules (some are way more resource intensive), amount of caching, etc.
I recently moved a semi-popular blog (wisebread.com) off shared hosting to a beefy VPS (dedicated specs, but not strictly a dedicated box). The extra resources were nice, but what really made a difference for us was using caching wherever we could.
We're using 40+ contrib modules plus a half dozen custom modules.
I've found that it's not the number of contrib modules that affects performance, but what those modules do. For example, the service_links module does almost no work while the similar entries module is pretty database intensive. The key for us to get to a satisfactory features/performance balance was aggressive use of caching.
Just a few tips I wish I had when I got started:
1. Install a PHP accelerator. Most shared hosting already have this installed, but it wasn't on our VPS. Installing eAccelerator (our hosting -- servint.net -- did it for me in less than an hour) reduced our memory usage per httpd thread about 40 percent.
2. Install the block cache module. We have a couple of sql intensive blocks (generating "related" or "popular" lists of nodes related to the current node) that REALLY benefited from block caching. Page generation times (from the devel module) was cut in half for logged in, registered users.
3. Turn on page level caching, and set a minimum cache lifetime. I can't even imagine a production site not having page level caching on. The load times for anonymous users must drive them crazy! Just turning on caching was a big help. If your site gets lots of new content (new nodes or comments), a short 1-2 min minimum lifetime will be an even bigger boost in performance.
4. Use caching in custom modules. Check out Lullabot's excellent tutorial on drupal's caching functions. Very very handy if you're deploying any custom modules.
5. Check your html. This isn't caching related, but all the tweaking doesn't help if each page is huge (eg., over 200k total). Even in this age of broadband, you still have to worry about dial-up users. Plus, it can't help your bandwidth bill if every user is downloading 1Mb per page! (We were at that point before....) The Full Page Test at Pingdom.com was helpful in finding all the unneeded, duplicate and missing elements on a page that slowed it down. It was also eye-opening to see how large our pages were. We reduced the amount of data that was loaded per page -- fewer teasers per page, fewer comments per page, encouraged users to use smaller sized pictures. Good old-fashioned webmastering here, but still very handy.
Good luck with your deployment. Getting into the code a bit can really help boost performance.
Cheers,
Greg
Thank you
Dear Greg,
Thanks for the great response and tutorial, it is really helpful.
Cheers, Val
http://www.newcomersguideusa.com
Yes and no
I don't see any reason to use the modules you need, but don't go adding any you don't. There are many modules available that can be replaced adequately by just a few lines of SQL and php, if you take the time to learn them. Such solutions are going to be considerably faster and more efficient.
As for page sizes, may I shamelessly suggest the Site Documentation module to help identify large pages (in the Node Summary section). And, yes, not only do you need to still consider dial-up users, but also who they are, if you know. For example, on one club site I maintain, the chairperson is dial-up, so that priority is higher than it might otherwise be. The same also goes for screen resolution (she has a very old computer and no plans on upgrading).
Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database
NancyDru
Subscribing
Quint