Slow Site, Very Very Slow Admin Pages

Hey Mark,

You mentioned caching (did you set both page and block?), but did you also implement the Bandwidth optimizations? Depending on the number of modules you have installed, they will each call their respective CSS and JS files, regardless if they are in use on the page.

Just a thought. :)

Same here...
I've disabled the update status module, I'm not optimizing the CSS and Javascripts, and the site itself runs fine, but the admin pages take forever to load (over 30sek).

Just wanted to add my two cents. Yeah, the update module definitely needs some work. I think it should still be turned on by default, as it is now. Most people aren't Drupal pros, and wouldn't know to check for updates manually. Updating the core is SO important. Seriously, a lot of people neglect to update the core... then they start having problems or someone gets in and throws everything for a loop... then they want to blame drupal. No, leave it on by default. BUT... I think there should be a note under the update module in admin>modules that informs users that "Update could cause some issues or conflicts with modules or server settings. If problems are encountered, you may need to disable the module. Be sure to check regularly for updates"... or something like that.

I went through one very frustrating day after I installed Image API, Image Cache, Guestbook, Acidfree, Simpleviews, and a few others. I started getting timeouts, errors, 500's, MySQL Has Gone Away, etc. I first thought it was one of the modules, so I removed each via ftp... nothing happened... still had errors. Now I was seeing errors with Notifications, which was also updated the same time. I checked everything: My host (InMotion) is awesome and totally up to date with everything, so I knew it wasn't them. I also knew that my php memory was set at 128M, which should be more than enough to do just about anything I'd want.

To make it short, I deleted update via ftp, and BAM... back to normal. Just to double check, I dropped the module back into Drupal, and got same errors. I changed some things here and there and got it all working again. But update was definitely the culprit. Oh yeah... although I didn't see any problem with my main page's loading time, my admin DOES take forever when update is enabled.

One more thing: Just a side note, but if you have a lot of modules running, your admin will be somewhat slow loading, but not 30 or 40 secs. I have over 100 modules installed; with update enabled (with performance enabled), it takes about 9-10 secs... without update: instantly.

To all: If you need to disable or remove update, MAKE SURE you stay up to date yourself. This is VERY important.

Chris
www.theparanormalsociety.org

I got the same problem "Admin pages were slow" and same solution "Disable Update Status".

Thank you for the useful posting.

Glad to see I was not the only one with this problem! I was wondering why it was taking so long to load the admin pages... Drupal is supposed to help speed up website creation. Slowing it down that much was really bothering me.

In my opinion the update module SHOULD be disabled by default. The update module in my opinion is not made correctly. Since every time you load any page it slows things down tremendously, that must mean the update module checks for updates every time you load a page? If that's the case and I think it is, its completely ridiculous and unnecessary! Like drupal updates are released that fast(ya right), that between the time you load 1 page, and the next, and update will be released...

Imagine all the drupal sites out there with the module enabled, tons of sites are connecting here to check for updates. You should not bottleneck a website by checking for updates constantly.

I propose two solutions...

A. Change the update module so that it only checks for updates every so often, like every 24 hours. So you/someone will get 1 slow page load every 24 hours, instead of all the time.

B. Not even have a module, and instead make it part of the administration part of drupal. A check for updates button instead so you can manually get it to check for updates and not even have any automatic update checker.

Updates are important, but the average amount of time between updates should be taken into consideration. Uselessly checking for updates does nothing but slow you down, when there are no updates.

Lets also not forget human beings aren't perfect. There could possibly be a mistake/bug in the new code which wasn't there previously, so if your site is updating automatically without even letting you know it updated, your site might break, and you wont have any idea why.

Ok, so I get why Update Status slows down some admin pages (modules page, status report, etc.), but I was experiencing slow loads (locally) just on admin menus. Two examples:

Administer - 35 seconds
Content Management - 17 seconds

These times were consistent. After I disabled Update Status, they both loaded in about 2 seconds. I realize those links actually show pages of admin options (which are also menu items), but they don't show ANY version or status information, so I don't understand why Update Status would make them so slow. Can anyone explain it?

I did a recent experiment with the modules pages, loaded 100+ modules, checked module page load then removed most of the modules and checked again.

It would appear that having many modules in the module folder does in fact slow the module page down to a crawl taking 30-40+ seconds or more to load. Drupal seems to use up resources just to scan every module even though none of them are enabled.

5 seconds (no modules) 30-40+ seconds ( 25+ modules) and longer if you have 50 or more modules.

With wordpress plugins, never had any slow plugin pages, the number of plugins were irrelevant but not with drupal.

+

Subscribing

Though I have disabled the update_status module, there is no improvement. Two other same drupal websites - total three (prod, staging & development) are hosted in the same server. prod & stag are working fine. Though all the three are identical, dev site is very slow.

I tried the following things, but could not get a fix:

1. disabled update_status module
2. checked the following two settings in conf file:
a. query_cache_type=1
b. query_cache_size=16M
3. installed boost, block cache, query cache and memcache modules
4. ran cron manually.
5. disabled devel modules

Can some one please give your suggestions?

- Sekhar.

This is whay I do, as a workaround for the problem, I'm stuck with this until a better solution is found. Once a week, I run the following commands to update.

drush en -y update
drush up
drush dis -y update

This will enable the update module as required by drush, then it will look for any updates and ask the user to update if it finds any update. Finally, it will disable the module again.

*This is not ideal*, it works, but is not ideal. If anyone finds a better solution for this I'll appreciate it. Using the proxy patch didn't work for me and the update usually takes about 45 minutes in one of my sites. Is totally insane.

If you are running your environment on an AWS VPC or EC2, you will also need to check your security group configuration settings. If you port :80 access is restricted to a specific internal network IP, then after installation and any time cron runs, the update script cannot access the outside web and will return the HTTP Access Error. A remedy I have found for this is to assign the server's Elastic IP to the port :80 security group as well. An example would be as follows:

• Current Internal Network IP: 10.1.2.3/10
• Current AWS Elastic IP: 123.2.2.3
• Current TCP :80 Restriction: 10.1.2.3/10
• Additional TCP :80 Access: 123.2.2.3/31
• Additional TCP :80 Access: 123.2.2.3/32

It is important to note that the trailing /31 and /32 are settings required by AWS.

Save the security group, run a drush cron and see if your error report clears out!