Troubleshooting performance issues on a slow web site

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
kbahey's picture
Start: 
2009-01-15 19:00 - 21:00 Canada/Eastern
Event type: 
User group meeting

For our January meeting, we will cover a topic that popular sites face sooner or later as they gain enough traffic.

It may be that your shared hosting provider is asking you to move your site away on their oversold server.

It may be that at certain times of days the site is like molasses in January.

It may be that the site has lost (or never had) the snappiness we all long for.

It may be that your site went unresponsive when it was on the front page of a popular site (Digg, Slashdot).

Whatever the case may be, this session is for you ...

We will do a forensic analysis of a real life slow site volunteered by one of our members. We will try to analyze where the problem(s) lie. We will follow that with solution(s) to speed the site.

Important Note: Please note that the day of week has changed. We are now meeting on the third Thursday of the month.

Comments

Reminder: Thursday 15 January

kbahey's picture

Reminder: Our meetings are now on the third Thursdays of every month.

The coming meeting is at 19:00 at the same place, on January 15.

We have a case study on how to speed up a slow site.

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

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

Molasses in January

chaslinux's picture

It's January, are you going to bring Molasses to the meeting tonight. ;-)

I would ....

kbahey's picture

I would, but the way I eat molasses with tahini and pita bread would be too messy for the meeting ...

You can stay home and watch G.W's farewell speech ... NOT ...

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

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

Slides

kbahey's picture

Thanks to the brave souls who despite the cold snap showed up for the talk.

Here are the slides from the presentation.

Diagnosing and Speeding up a Slow Drupal Site - A Case Study.

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

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

Thanks for the talk

deviantintegral's picture

It was quite informative.

I owe Khalid a huge apology.

mdowsett's picture

I owe Khalid a huge apology. I was the 'owner' of the site he used to optimize as a case study. I was supposed to be there last night to co-present with him. And after all his help, I missed the meeting. I didn't realize it was the third-Thursday of the month and when I did, it was too late to make it to the meeting (childcare).

My apologies once again Khalid.

And since Khalid helped me with optimizing both my server and the single site that was on my VPS, I've had no complaints from the client (SQL crashing & white screens), a huge boost in performance and I've been able to host other domains on that VPS with great performance...just as I expected I should have with the VPS I signed up for.

Great presentation

chaslinux's picture

Thank you again Khalid, the presentation was very helpful. I'm always stoked after Drupal presentations (it's only finding the time to start paying attention to my site - run on bad shared hosting [GoDaddy], but it's extremely cheap and a low volume site).

I'd also like to thank Paul for coming out and everyone else. I really appreciate the help and consideration with setup and tear down.

http://www.charlesmccolm.com/

Tagadelic

mandclu's picture

Sounds like a great presentation, sorry I missed it.

I noticed you mentioned Tagadelic, which I've had issues with too, specifically memory errors on the modules page. Yes, I'm occasionally guilty of the open buffet syndrome myself, though in my case no matter how much memory I throw at the memory seemed to solve the error, but disabling Tagadelic did.

It's too bad because I love the effect, especially if you pair it with Cumulus. I imagine it's hard on the server because it's constantly pulling the number of nodes associated with a large group of terms. I've been thinking, a lower overhead way to implement this would be to allow the module to keep its own cache, so it could draw from that, and maybe even just update it as a cron job.

Scale ...

kbahey's picture

It depends on how many nodes and terms you have.

On small sites, it does not have much of an effect.

If you have free tagging and got thousands of terms and thousands of nodes, then yes, it is heavy on the server. Moreover, the underlying tree query in the taxonomy module has a static that keeps the tree in memory, and that is probably where it bails out in your case with a memory error.

The way to mitigate that is by enabling the block cache for it.

A patch to the module to update via cron is ideal. Go for it!

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

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

It's on my to-do list...

mandclu's picture

It's on my to-do list...