Optimizing my site (any advice appreciated)

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
sifuhall's picture

I recently converted a somewhat big site to Drupal 6.

We currently have:
~13,000 registered users, usually anywhere from 50 - 100 online at a time.
~23,000 nodes
~380,000 comments

I'm running on a VPS with 4gb ram, 200 gb disk space.

I have drupal page compression enabled, optimize css and js enabled.

My host has installed xcache for me.

I really love the drupal framework but my users are very displeased at my current speeds.

Some of the complaints I have received are:

"Speed- slooooooooooow. Agonizingly slooooooooow. 20+ seconds per click."
"Between 'click' and 'open' I often need to shave and get the oil changed in my car."
"I am not happy with this new format so far. Very very sluggish!"

Tough crowd, huh?

So I want to do my best to speed up the site.

I have tuned mysql extensively using by mysqltuner and dbturner

Some other items I have considered are:
* litespeed or nginix (but I need .htaccess for some parts like image cache, right?)
* dropping xcache and going to apc
* memcache (I've read it can be very difficult to configure correctly?)
* boost or varnish (but anonymous users are not my highest concern at the moment)
* What about solr for indexing? Does that still rely on the drupal search_index table?

Would any of these be worthwhile to use?

If so in what order and how much trouble and I going to have configuring these?

I'm really open for all suggestions and I'm sure my users will begin leaving soon.

Comments

Quick tips

mikeytown2's picture

nginix & solr are awesome in terms of improving performance. Views caching is also helpful. If using memcache, use pressflow as well.

Pressflow links:
https://wiki.fourkitchens.com/display/PF/Modules+that+break+caching,+and...

Memcache links:
http://drupal.org/node/795004#comment-3611924 - Something to be aware of
https://wiki.fourkitchens.com/display/PF/Using+memcached+with+Drupal+or+... - Slightly outdated, but still good info.

Identify what is slow and target one thing at a time. Given enough time, you can take a 20 second page down to under a second most of the time.

If pages are taking 20+

dalin's picture

If pages are taking 20+ seconds to load than I highly doubt that switching to nginx or lighttpd will make a difference. It sounds like your bottleneck is somewhere else. Like @mickeytown said, you first need to identify what is slow. My guess would be slow queries. You can use the devel module to see how much of your page generation time is spent in the database, and which are the most troublesome queries. Chances are that you have a few troublesome queries, possibly caused by really complex views, that are backing everything up.

--


Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his

Rule out the front end

kbahey's picture

Install Firebug on Firefox and load a page, check Firebug under Net and Net / HTML.

See if this is really a backend issue, or a front end issue. It could be that there is an ad or piece of static content that loads from another slow server. Or you have javascript that delays page being ready for some reason.

Firebug will also tell you how much "waiting" you have for the main HTML. If it is (say) 800 ms, but the page still renders after 5 seconds, then it could be a front end issue.

Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.

Confirm the ailment before taking any medicine.

Alexander Allen's picture

The first thing I would do is like @kbahey said use the 'net' tab in firebug to rule out external scripts, images or ads that might be causing your site to hang. Just 10 youtube videos and 10 flickr slideshow embeds on any single page and an otherwise decent site will perform drag it's feet.

However, given the size of your site I would suspect initially of two things:

1) Like @dalin said, complex and time consuming queries. Also duplicate queries.

If the devel module indicates the queries come from Views, Views comes with efficient caching mechanisms included. However these are not enabled by default. You must enable Views caching manually.

If the heavy queries come from contributed or custom modules, you might want to take a look at Jeff's article on static and external caching: http://www.lullabot.com/articles/a-beginners-guide-to-caching-data

2) Errors.

You can start from the outside in. Check both the web server and PHP error logs just to make sure there is not a problem in your PHP configuration or hosting environment. For example if you are using PHP 5.3.x, some modules might not be compatible with it.

Then check Drupal's watchdog. If it's not enabled you might want to enable it in the modules admin page. A lot of times watchdog will tell you exactly in what line and module the error is being generated.

And what if you follow all the excellent recommendations posted before, cache Views like there's no tomorrow, see no duplicate queries, there are no errors reported in watchdog, and your site is still slow? I am not sure you will get to this point, but if you do, remember that not all errors are caught by any of these error logs. Some errors you have to catch them manually.

Enable PHP error reporting in your Drupal installation. Browse to the pages your users are complaining the most about and see if any errors are surfaced. Don't turn on PHP error reporting on your production environment, only on your development or staging site.

Finally, with Zend Studio and the Zend Studio Toolbar you can profile a site. The profiling function will give you a briefing of all the functions that ran on any particular page, and how many milliseconds each one took. You'll identify bottlenecks in a breeze. Getting the Zend Studio properly setup to use the debugger is the tricky part, but it's not so difficult. Here's a couple links I used:

Configuring Eclipse for Remote Debugging with Zend - http://drupal.org/node/157609
Quick-and-Dirty Debugging - http://www.lullabot.com/articles/quick-and-dirty-debugging#comment-2905
Squash bugs in PHP applications with Zend Debugger - http://www.ibm.com/developerworks/opensource/library/os-php-zenddebug/
Remote Debugging and Breakpoints - http://kb.zend.com/index.php?View=entry&EntryID=421

Basically there's three components for debugging and profiling I use:
- Zend Studio http://www.zend.com/en/products/studio/
- Zend Studio Toolbar
- Zend Debugger Extension (also called Studio Web Debugger). Comes for Linux, Mac, and Windows in both 32 and 64 bit flavors.
You can download all three components for free from here: http://www.zend.com/en/products/studio/downloads

Some people also use Netbeans and Xdebug, but I haven't tried those.

You now have become powerful, may the force be with you.

litespeed or nginix (but I

Garrett Albright's picture
  • litespeed or nginix (but I need .htaccess for some parts like image cache, right?)

Imagecache works just fine with Nginx; you just need to use its configuration options to configure it just as Drupal's .htaccess file does. Likewise with Lighttpd. Not sure about Litespeed, but there's a good chance it can handle it as well. Just because these alternative servers don't use .htaccess doesn't mean they can't do the same things that Apache does.

If you're interested in Nginx, I'd suggest you check out the Nginx group here on g.d.o. There's one for Lighty as well.

But as dalin said, you may wish to look elsewhere for bottlenecks before considering switching server daemons at this point.

  • dropping xcache and going to apc
  • memcache (I've read it can be very difficult to configure correctly?)

Xcache is often overlooked when it comes to opcode optimizers and cachers, while APC and Memcache get all the attention. However, I personally haven't had any problems with Xcache, and doubt it's the cause of your current problems. I'd say stick with it if it works.

  • boost or varnish (but anonymous users are not my highest concern at the moment)

They may not be your highest concern, but Boost is so easy to set up that I definitely think it's worth the return even for sites that don't have much anonymous traffic. Low-hanging fruit. If you have the resources and the know-how, you can go for Varnish instead.

Thanks for the replies. Slow

sifuhall's picture

Thanks for the replies.

Slow and duplicate queries look like the first place to start.

For example, using devel, just to load the initial forum page:

Executed 1387 queries in 1920.69 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 3430.88 ms.

There are many duplicate queries being executed.

Is there a standard method to eliminate or reduce duplicate queries?

Troubleshooting Performance issues

SocialNicheGuru's picture

This is the thread that I am looking for. I am really delving into this and I appreciate this thread.

FRONT END:
I took a look at firebug:

  1. Page weight: the Get is taking a long time.

I notice that sometimes the page weight varies. On my sites I have found that:
i. Admin module adds a great deal to the page weight
ii. lots of blocks or a module like quicktabs can also add to the page weight
iii. devel or any monitoring scripts that you might have running adds significantly

  1. Js and CSS

I am also attempting to use:
javascript_aggegator
css_gzip
cs_emimage

While I can't seem to get the gzip component to work (http://drupal.org/node/752594#comment-3789856), there are fewer requests which is a good thing. the module css_emimage makes the css file larger by including images that are specified in stylesheets. It would be great if I can get this compressed too.

Javascript_aggegator is returning js.min. Again better to get this compressed.

Java/CSS is served from files: sites//js and css

If I am using javascript_aggregator, css_gzip, css_emimage which bypasses APC, why use APC? Is it only for php scripts?

CACHING:
Anonymous Caching:
Boost for all anonymous user requests.

Boost using cache directory in the drupal root to serve pages. The logic I believe is that it is faster
Does it bypass javascript_aggegator and css_gzip altogether?

Authenticated:
PHP: APC, Cacherouter, AuthCache

WAITING VS. RECEIVING TIME:
In Firebug, a page might take 5s to load. Of that 5 seconds, 4.59s is spent waiting. What causes this? Any tips on how to troubleshoot this directly. This is because of issues in the backend with the database specifically?

BACK END:

  1. After looking at devel menu_cache seems to be taking a long time and is called constantly. Is there anyway to cache the entire value and just call it once?

  2. After looking at my slow mysql queries, information_schema seems to take a long time (> 15s sometimes). How do I troubleshoot this? I know it is directly related to my Drupal install.

  3. Lots of modules: Does Drupal read/load all modules on every page load? I have read that the more modules you have the bigger the performance hit. Is this true? Is this information cached somewhere?

I highly suggest that you not

Garrett Albright's picture

I highly suggest that you not use css_gzip and instead use your web server to send Gzipped files. That's work that should be happening at the server level, not in PHP.

Using parallel or loading external images or js

SocialNicheGuru's picture

I have placed my $script variable in the footer.

I notice that sometimes the pages will load slowly because of external images or js. Gmap is a great example.

has anyone used parallel: http://drupal.org/project/parallel

to load external images, or js, css?

Would it be helpful to use it for internal js, css, and images too?

If you have experience with this, I would love to hear it.

CDN Module

mikeytown2's picture

Parallel has been merged into the CDN module; everything that Parallel could do, CDN can do now.

Using nginx should give you a

halcyonCorsair's picture

Using nginx should give you a considerable speed boost for all static content (eg. boost, imagecache, etc, etc).

Also, I'm assuming you have mysql's query cache on with a large amount of memory available?