Posted by jdcreativity on November 12, 2010 at 6:20pm
I've been having some occasional trouble where my site slows to a crawl.
Does anyone have any best practices for optimizing Drupal on lower memory configurations.
Best practices for optimizing Drupal on lower memory configurations
Group organizers
Group categories
More Specifically
- Boston Proper (212)
- Cape Cod (30)
- Central Mass (33)
- Metro North (63)
- Metro South (39)
- Metro West (112)
- North Shore (57)
- South Shore (39)
- Western Mass (40)
- Meta-Boston (59)
Hot content this week
-
23 weeks 2 days ago
Comments
Optimizing
Can't say I'm an expert on this but these are the simple things to rescue a site from immense slowness (that worked for me):
Disable any modules you aren't using. - You don't need to uninstall or remove them, but don't use anything you don't need.
Set Views to Cache - I already have 60 Views, all of which were created without caching enabled - so each time they load they load afresh. This is good but can be memory intensive. I found that generally everything that isn't on the front page or running a query central to the site's functioning can be set to cache - you'll know if you cache the wrong ones because your site will slow down when you load those pages. (In OMP sites the schedule view was one of these.)
To set this up go to YOURSITE/admin/build/views/list, chose a view to cache by clicking Edit and then on the Edit View page. Generally this wil be on the Defaults> tab on the left, and generally you can apply this to every aspect of a View - Page, Feed, Block, etc., but in some cases you might want to select a different tab. Under Basic Settings scan down to Caching - which will either have a time listed after it or say None. Click None which opens the Defaults: Caching block. Select Time-based, click Update and this block will refresh with two dropdown options for time. I've been setting these each to an hour for any View that's called pretty regularly, and 6 hours for those that are hardly used. You then need to click Update, which should update the Caching field above, AND then click Save to commit the changes.
Boost - This nifty module lets you "boost" your site's performance without too much work. There are a couple of things to do after installing for setup. As it says on the module page, either read readme.txt or go to YOURSITE/admin/reports/status and correct the errors next to Boost (this is actually pretty simple).
Then go to YOURSITE/admin/settings/performance - I set up Boost with these options:
Caching mode: Normal (recommended for production sites, no side effects)
Minimum cache lifetime: 1 hour
Gzip page compression (Boost & Core): Enabled
Block Cache: Disabled
Optimize CSS files: Enabled
Optimize Javascript files: Disabled
And it seems to work for me. There are even more options here, YOURSITE/admin/settings/performance/boost which I've mainly left alone except for deselecting Cache .js, because I was advised not to cache Javascript.
And if the above doesn't work and you want to do the complex way there's Memcache.
Regarding Boost, it may not
Regarding Boost, it may not be advisable to use that on a site that is updated on a regular basis. It may cause older configurations or older versions of for example javascript files to be used from cache, instead of the updated files.
I'm not an expert in the field, and on our site on a low-memory hosted server we're regularly experiencing slowdowns and time-outs. But from what I understand, Boost may cause more issues than it solves on a site like ours, that we work with frequently.
Boost
Boost on dynamic sites is relatively okay for me. Note that each time you edit or create a new node, make a major configuration change (such as enabling/disabling a module), Boost will generally clear all static pages, enabling a refresh the next time someone visits. Boost will also clear static pages if configured correctly to respond to cache clear requests (which usually happen during cron jobs). Also be aware it is not always compatible with Views and caching in the same way (sometimes you need to go clear Views cache manually before clearing all static pages in Boost MANUALLY).
You can also filter Boost pages. This is why you should make sure your paths make sense and you are not going to have every page with a really important dynamic element. Even if you do, such as an auto-updating recent comments block (and such a page becomes cached with Boost AND you have block cache enabled), then that content is not part of Boost and will work fine (however if you define a block like such in a module, you should use 'cache' => BLOCK_CACHE_GLOBAL in your module).
To Boost or not?
After singing Boost's praises above, I'd like to add the caveat that should probably apply to all Drupal modules: it's best used when you understand everything that it's doing, and how it plays with other modules.
In Boost's case it got my site working much faster, but as I was still developing it, it did some unexpected (to me) things, even with it disabled. It required a full uninstall after much head scratching to get things working again.
Boost is undoubtedly a powerful and useful module, but use with caution, especially on production sites.
And as with much advice, ignore this addendum if you enjoy puzzles and challenges, and can quickly make your own custom solutions.
PCRE
Have a look at settings.php and uncomment these:
ini_set('pcre.backtrack_limit', 200000);
ini_set('pcre.recursion_limit', 200000);
Adjust the number and see if it makes a difference.
Get rid of heavy modules
@synchlayer: One of the first things I would do is to get rid of the "heavy" modules: Panels, Views, CCK, etc. Of course that means you will probably have to write a site-specific module to replace those functions. But I have never seen a case where those functions weren't much smaller - and faster. If you really want to have those modules, then get more memory. And don'r forget that ImageAPI is going to complain if you have less than 96MB. Frankly, these days, I won't even try Drupal with less than 128MB. If your host won't give you at least that, there are plenty who will.
Nancy Dru
I agree. Definitely go with
I agree. Definitely go with pager_query() and theme('page') to do displays instead of using Views. It's always faster.
While I used to love to use CCK and Views together to make a site real fast, it has proven to be more trouble than it's worth the speed of building the site. Namely, when you decide to do something Views cannot easily do and you don't want to modify Views core code and you just can't find the hook you need (because it doesn't exist). Not to mention the amount of overhead Views has while it's not in caching mode. Do what /node does and extend upon that instead of using Views.
Same goes for CCK; I hate it's field mechanism. It has a nice UI in sorting the fields the way you want, you can share fields across different content types, but there's no doubt you can write your own node type module with its own field, a table you can trust will actually exist, and templates/theme functions you know how to use because you made them.
Only thing on making your own node module is if you will need to use Views eventually. Consult the Views API on how to integrate your data with Views correctly (namely hook_views_data()).