By ergophobe on

I've run several Drupal sites and some have quite complex content types, but the current one is just dieing when I try to change configuration settings with content types, especially when I try to rearrange the field (i.e. change the weight/sort order for fields).

Suddenly, I just can't get it to function. I've tried disabling as many modules as I can and it still times out. The server itself is fairly responsive if I try to access tables via PHPMyAdmin, but with Drupal it's death.

Anyone run across this? Have any decent solutions? By they way - this is more or less a test site running on shared hosting, but other drupal sites have no issues on this account. I have the basic performance optimizations in place (normal caching, block caching, JS aggregation, etc).

⋅ Categories: Drupal 6.x

Comments

captainhirez’s picture

captainhirez commented

I have the same issue. Currently the site is on a LAMP setup but when I ported it to our IIS environment for development, whilst improved it was still comparativley slow when managing fields.

I've been through the usual suspects of "how to tune mysql" tutorials that seem to do nothing to improve things. Obviously it doesn't do this on every install but only on this one site so any help anyone has would be greatly appreciated. As of today, the site is running all the latest modules and build of Drupal.

Phpmyadmin is a fast as lightning. If I can provide any more info please let me know.

doublejosh’s picture

doublejosh commented

Similar issues here.
Both saving content types and views takes up to a minute. And I know is hurting performance at that moment.

The tool I've relied on in the past is Devel Performance Logging, which shows all the queries on the page load and organizes by speed.
This is a big hit in and of itself, so should only be run on development environments... but it gets you some insight.

In that past we've found examples of pages that need a custom display instead of a view (Drupal 5).
However now I've seen this project to fix that issue: http://drupal.org/project/dbtuner

BennyLitmus’s picture

BennyLitmus commented

This is driving me insane... every time I save changes on either the Manage fields or Manage display pages for my content type, it takes almost 3 minutes for the page to come back with "Your settings have been saved". This content type has ~70 fields.

I'm running Drupal 7 with LAMP stack. If I check top, there is ~50% cpu usage on httpd and mysqld processes. I've got 2GB ram with 400MB free on this VPS server.

devel query logging is not very helpful because when you click on Save, the return logging is for fetching the fields not for saving them.

Anyone run into this issue and have suggestion on how to solve this?

Thanks!

BennyLitmus’s picture

BennyLitmus commented

I was able to cut the save time from 3 minutes to 1 minute by disabling the RDF and Microdata modules. Using XHPROF, I profiled what was taking so long during the save and I could see a lot of CPU time was spent in these modules. The other thing which was slow was executing queries in the DB but I have not tuned that further because read operation are fast. Most pages on my site like opening the homepage or executing views returns in ~1 second. The operation which usually take upward to one minute include:

- Saving content type manage fields
- Saving content type manage display
- Enabling/disabling modules
- Saving view definitions