Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

I'm using a drupal site with a theme from rockettheme.

The users are member users. The problem is for unknown reason the site is very slow. Takes around 20 seconds to open the page.

I have tried switching the VPS, but no performance gain.

I'm not using many modules, that would bog down the site.

What possible solutions should I look at to increase the site's speed to bring it to open in normal time.

Executed 120 queries in 113.52 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 2534.15 ms.

Executed 87 queries in 24.6 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 2609.59 ms.

Executed 123 queries in 41.05 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 1282.27 ms.

I don't guess these are normal.

share|improve this question
    
Is it 20 seconds before the page even starts loading, or 20 seconds total? –  DisgruntledGoat Sep 21 '10 at 23:26
    
You stress member users, which would indeed be an important hint, so just to make sure: are you implying the 20 seconds do only apply to logged in users, but not for anonymous site visitors? –  Steffen Opel Sep 22 '10 at 7:11
    
The time is for anonymous users. I don't know if I'm allowed to , I would like to give the site link, so that some subtle flaws can be pointed out by community here. –  Nikhil Sep 22 '10 at 15:31
    
Could you please specify the respective versions of the following components in use: Drupal, jQuery, MooTools (more on that later); ideally Apache, PHP, MySQL for completeness as well. Without being able to look at the site this information will ease properly judging on the various artifacts presented/discussed already still. –  Steffen Opel Sep 23 '10 at 13:19
    
I've updated my answer regarding possible conflicts between jQuery and MooTools - please do provide the requested versions still if possible. –  Steffen Opel Sep 23 '10 at 13:43

6 Answers 6

up vote 1 down vote accepted

Update:

I found one particular file mootools.js takes a lot of time to load in ylsow, but opening the file directly - there is no delay.

That's a pretty good hint eventually - is MooTools really required? Drupal uses jQuery exclusively in core and most contributed modules do likewise, so please be advised that using more than one major JavaScript framework at the same time, while possible, is generally not recommended by most developers, usually requires dedicated handling at least and might introduce all sort of weird (i.e. hard to debug) issues regardless:
You'll find many related posts within jQuery+MooTools on Stack Overflow, see this exemplary answer to Mootools and JQuery Integration mentioning huge page slow downs specifically.

Given that you are not using many modules I suppose only an isolated area of functionality is asking for MooTools specifically, consequently I suggest you turn that off entirely (i.e. make sure mootools.js is not loaded anymore) and see whether it makes any difference.


You might check out the various answers on a respective question on Stack Overflow - while they do mostly overlap with the ones given here in the meantime, there is some additional insight spread in the comments here and there.

Other than that I'd like to stress one important thing again, as mentioned by DisgruntledGoat and bpeterson76 already to some extent (+1 each):

Despite Drupal not being the fastest CMS in the first place, the page load times you are seeing aren't normal at all (though possible on badly configured systems/servers) - therefore you really should analyze and identify the cause(s) first, before applying optimizations of any kind! Sure, some recommended optimizations might help even without that, but the golden rule for performance (and other) optimizations really is to understand the problem rather than trial and error.

To get you started I'd like to comment on three topics raised specifically and provide a pointer to more thorough documentation regarding the subject matter below:

I have tried switching the VPS, but no performance gain

  • Okay, still you should check explicitly, whether the VPS and LAMP stack in use are performing normal in the first place (i.e. without Drupal)?
    • The answer from bpeterson76 addresses possible causes.

I think the main culprit is the theme.

  • Then you should verify this assumption, which is easily done by switching to another theme, preferably one with known performance characteristics, e.g. the default Garland theme.

I don't think the SQL query is at fault.

  • You already realized that you should verify this assumption as well - this can be approached in various way, I'd start with the devel module, which has various offers regarding Performance Logging including SQL execution time (the other stuff is useful as well of course).
    • Please note that for more precise SQL execution times you should resort to dedicated tools for the database system in use.

All this, and a whole lot more, is addressed via Drupal caching, speed and performance - this resource hub might look overwhelming at first sight, but as I said understanding the problem is key for solving performance issues - to allow for a jump start still eventually, I specifically recommend to read Server tuning considerations, in particular section Understanding and configuring your stack for performance.

Good luck!

share|improve this answer
    
Ouch, just realized that you already started with the devel module in the meantime, sorry (got distracted while writing and forgot to recheck before posting) - I'll keep the answer for the moment still and consider adjusting or deleting it eventually depending on how the topic evolves. –  Steffen Opel Sep 22 '10 at 17:19
    
Thanks for such a keep input. Since you have seen the devel log I posted. I would be helpful to know what can cause the Page execution time to go so high. What should be the normal. This would certainly help me in getting to the root of the problem. –  Nikhil Sep 22 '10 at 18:40

If the page load is 20 seconds then there is likely a major bottleneck somewhere. APC might reduce it to 5-10 seconds but that's still not really good enough for the server-side. And it won't help if the bottleneck is a SQL query.

Modules can slow the site a little but not by that much. Try disabling each one in turn to see if there are any big improvements.

Another solution if you can't improve the speed that much is to cache pages as much as possible. With various sites (using CodeIgniter) I've found that it makes a HUGE difference - the server responds instantly and you really just have the client-side time.

Depending on what you're including in the 20 second delay (i.e. server-side only or client-side as well) you may find Yahoo's Best Practices page useful.


To determine where the bottleneck is, have a look for profiler modules for Drupal (if there are any), they would tell you in which parts the code is slow. Or, you could add your own timing code to the template:

$time1 = microtime();
// some chunk of code
$time2 = microtime();
// another chunk of code
$time3 = microtime();
echo 'First chunk: ', ($time2-$time1/1000), ' seconds';
echo 'Second chunk: ', ($time3-$time2/1000), ' seconds';

Repeat that in various places and you should be able to narrow it down to a section or two that is running for 10-20 seconds.

share|improve this answer
    
I don't think the SQL querry is at fault.. I think the main culprit is the theme, but just to be sure SQL is fine, how should I proceed. –  Nikhil Sep 22 '10 at 11:15
    
@Nikhil: Have you tried different themes? If the problem goes away with a different theme (using the same modules) then it's definitely that. –  DisgruntledGoat Sep 22 '10 at 16:28
    
I might be wrong, I just posted the devel module performance logging results. Are SQL at fault too. –  Nikhil Sep 22 '10 at 16:28
    
@Nikhil: Yes, over 80 queries for a page is a heck of a lot! But it says they only took 113 ms so that's unlikely to be causing a big problem. –  DisgruntledGoat Sep 22 '10 at 16:38
    
So, I was right the SQL queries are not at fault. Its more likely a theme problem. I'm installing APC. I let know the progress, so others can benefit. –  Nikhil Sep 22 '10 at 17:23
  • Use a opcode cache like APC
  • Use a tool like xDebug to see where your bottlenecks are. That way you know what you need to address instead of just guessing.
share|improve this answer
    
yes, I was thinking about the same.. I see on some websites, they have measured the time taken on their server to execute queries. How can I do that too. The 20 secs time I have measured by counting. Is there some system available to do this. –  Nikhil Sep 21 '10 at 18:06

When building PHP apps, I've found I can pick off low-level bottlenecks using Firefox or Chrome's developer tools. Click on the resources tab and watch as the elements of the page load. It's especially valuable when you're working with XHR requests (AJAX).

Start by pinging the server. I have a Dev machine that was in a similar situation the other day....The Dev machine is crawling, taking 10+ seconds to load. But, I have identical code on another identical (but dedicated) server runs lightning fast. Doing ping tests, it's painfully slow. Turns out, the machine is shared and one of the other people with an account on the server is running an ultra high-bandwidth site (likely adult site) that is slowing down everyone else. That offending site is now being moved off by the host.

Xdebug is certainly a good option as mentioned above. But it doesn't always get to the source of the problem if there aren't errors being thrown. I'd start with the error log first, ensure more aren't being created. Then Xdebug.

I'd follow with disabling features one-by-one. Also, it'd be worth monitoring server load to ensure that something unrelated isn't bogging down the MySql or Apache processes.

Finally, if the problem still isn't fixed, I'd isolate the areas I think are causing the problem and insert start/end microtime timestamps that I output to log or email. It sounds silly easy, but I've found 200%+ performance increases in code using this method.

share|improve this answer
    
Going by your advice, I used yslow in firebug using mozilla. I found one particular file mootools.js takes a lot of time to load in ylsow, but opening the file directly - there is no delay. –  Nikhil Sep 22 '10 at 16:09
    
the drupal is running on a vps, tried disabling features - no problem found. I guess, I'll try with Xdebug. –  Nikhil Sep 22 '10 at 18:36
1  
Nikhil, one speed improvement that's been debated over and over on stack* is to load your JS framework files from a CDN such as Google. Here's the link to get started: code.google.com/apis/libraries/devguide.html. I'm not sure if that's what you meant by opening directly, but it can help. –  bpeterson76 Sep 22 '10 at 22:36

is caching turned on in /admin/settings/performance ?

It's worth double checking before you get into more complicated solutions.

share|improve this answer
    
I know it's a bit obvious but I felt it had to be mentioned –  WalterJ89 Sep 22 '10 at 7:39
    
Caching is worth turning on but that doesn't solve the original problem. Once an hour (or however long the cache is) a user will have to wait 20 seconds for the page to generate. –  DisgruntledGoat Sep 22 '10 at 10:14
    
yes, it is turned on. Thanks for pointing it though. –  Nikhil Sep 22 '10 at 15:32

I recommend to use Postgresql, drupal supports it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.