3

I have a Drupal-powered site that seems to have neverending performance problems. It was butt-slow about 5 months ago. I brought in some guys who installed nginx for anonymous visitors, ajaxified a few queries so they wouldn't fire during page load, and helped me find a few bottlenecks in the code.

For about a month, the site was significantly faster, though not "fast" by any stretch of the word. Meanwhile, I'm now shelling out $400/month to Slicehost to host a site that gets less than 5,000/uniques a day. Yes, you read that right. Go Drupal.

Recently the site started crashing again and is slow again. I can't afford to hire people to come in, study my code from top to bottom, and make changes that may or may not help anymore. And I can't afford to throw more hardware at the problem.

So I need to figure out what the problem is myself. Questions:

  • When apache crashes, is it possible to find out what caused it to crash? There has to be a way, right? If so, how can I do this? Is there software I can use that will tell me which process caused my server to die? (e.g. "Apache crashed because someone visited page X." or "Apache crashed because you were importing too many RSS items from feed X.") There's got to be a way to learn this, right?

  • What's a good, noob-friendly way to monitor my current apache performance? My developer friends tell me to "just use Top, dude," but Top shows me a bunch of numbers without any context. I have no clue what qualifies as a bad number or a good number in Top, or which processes are relevant and which aren't. Are there any noob-friendly server monitoring tools out there? Ideally, I could have a page that would give me a color-coded indicator about how apache is performing and then show me a list of processes or pages that are sucking right now. This way, I could know when performance is bad and then what's causing it to be so bad.

  • Why does PHP memory matter? My apparently has a 30MB memory foot print. Will it run faster if I bring that number down?

Thanks for any advice. I spent a year or so trying to boost my advertising income so I could hire a contractor to solve my performance woes. I didn't want to have to learn all this sysadmin voodoo. I'm now resigned to the fact that might not have a choice.

2
  • you're paying $400 a month... you can afford to hire someone to look at your server, if only for a quick checkup.
    – gbjbaanb
    Apr 11, 2010 at 0:59
  • make sure your mysql database is optimally configured: use ./mysqltuner.pl and ./tuning-primer.sh these are both noob-friendly and provide clear advise.
    – pixeline
    Dec 7, 2011 at 12:44

2 Answers 2

1

Drupal can scale really well; talk to some webmasters in their community and you'll find people that are exceeding those numbers on a regular basis, so I can't say it's an inherent issue with Drupal. Couple of things come to mind though: do you have caching enabled? You sure it's not your database (MySQL/Postgres, etc.)? what kind of hardware is your site running on? Are there any other sites on it? Please provide more details; there's too many unknown variables right now.

1

You didn't really provide much technical info, but one of the easiest and most effective optimizations for Drupal (and other big PHP applications) is using APC, memcache or similar.

APC alone is really easy to setup, and very effective. Here are my settings that seem to work well with Drupal (in the php.ini file):

extension=apc.so
apc.apc.stat = 0
apc.include_once_override = 1
apc.shm_size = 90

realpath_cache_size = 256K
realpath_cache_ttl = 180

The apc.shm_size size is most important (max MB of server memory used for .php filecache). Usually a lower size is enough, but if this cache is too small the cache will be almost useless. For most Drupal installations "50" would be enough. However if you have several active Drupal installations on the same server that are NOT multisites you need to set this even higher.

If you're using APC, you need to make sure Zend Optimizer is off, they don't work well together. APC alone can do increase page load speed 30-40%. If the shm is set too low page load speeds dont increase.

Also, I wonder if the guys doing the initial optimization actually knew Drupal and did Drupal optimizations or just general server stuff. You probably have these set, but to make sure you got proper settings on admin/settings/performance . That is:

Caching mode: normal
Page compression: enabled
Optimize CSS files: enabled
Optimize JavaScript files: enabled

All of these are very effective.

You're also probably using Views, which can be optimized in many ways, but each View can also have it's internal cache, and a cache-lifetime. If you caching your pages anyway and the users are mostly anonymous, it wont have a big effect though.

There are many more ways to optimize (and you probably still should to learn the administration stuff). If the Drupal log at admin/reports/dblog doesn't show the errors you're looking for, for example most fatal errors and "white screen errors" never make it.

  • Apache crash info You should try to locate the apache and/or php logs for more info why it crashed. For example:

locate error.log or locate php.log and the use the location to see the last log messages: sudo tail -n 100 /var/log/apache2/error.log <-- a sample path from my server When you find the error, google it.

  • Monitoring apache "top" isn't very userfriendly but it's fast and works on pretty much all UNIX machines. I usually use it to see if apache2 or mysql are choking.

  • Memory usage If the "devel"-module tells you a page load takes about 30M, it's pretty normal for a Drupal module with lots of modules. I have some installations using more (like 40M), but many also use less. My current project uses about 20M per normal pageview. De-activating unnecessary modules (or switching to more effective ones) is one way to lessen the memory usage.

While in php.ini, also make sure 'memory_limit' is not too low. Drupal does use a lot of memory, and for example all image scaling operations are very memory heavy. The default is very low. In theory you'll install might work with 35M, but I would set it to at least the double to make sure all operations work. Some might disagree but I'm usually having it over 100M.

If you want to do real hardcore Drupal optimizations, there are many guides, but this site is probably the most thorough: http://2bits.com/articles/drupal-performance-tuning-and-optimization-for-large-web-sites.html

And yeah, if you're paying that much a month for hosting you should be able to hire an expert for an hour or so :).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .