Drupal - Relationship of CCK fields and content types to performance?

Question

Hello,

I am helping someone with a Drupal 6 installation, and they are very distressed by the performance of the site, even though they are only in the phase of defining content types. Just loading the Modules list can take over 30 seconds, and importing a content type took close to 3 minutes.

This is installed on a large shared UNIX system, and I am running other D6 installations on the same server with no real problems (some slowness, but nothing quite this bad). I spent some time this afternoon disabling all of the non-core modules on the site, and was able to get the load time for the Modules list page down to about 5 seconds. As I re-enabled groups of modules, it seemed that the one that incurred the greatest performance hit was the CCK family of modules (a 15-20 second increase in page load time for the Modules list).

Again, I have other sites on this server that are also running CCK (and most of the same other modules) and not experiencing anything like this. The main difference is that this very slow site has a ton of content types and CCK fields defined -- 46 separate content types, and 162 CCK fields.

I'm drawing a conclusion that there is a direct connection between site performance (at least in certain operations having to do with creating and editing content types) and number of content types and custom fields, but I have not been able to determine exactly what the impact of this content types and fields is, and whether there is anything you can do to mitigate their impact.

I did install the Devel module, and found that the biggest performance drain on the Modules page is in the queries having to do with cache_menu, but I'm not sure if that's linked directly to the number of content types and/or fields.

Any guidance is appreciated!

Thanks, Paul

Answer 1

First off: The modules page is indeed a wicked beast, as it completely flushes all of Drupal's internal caches and rebuilds them to ensure that freshly-installed modules have the latest data. It's not a good predictor of site performance (since usually only specific administrative tasks flush those kinds of caches), though it is annoying.

Second: Importing content types ALSO flushes those caches, because CCK wants to make sure that everything is up to date as well. It's sub-optimal, but there you have it.

Finally: The number of CCK fields and content types you have DOES affect how much work gets done when caches are flushed and rebuilt. CCK pulls in all the information about all of the defined content types and their fields, builds a data structure to describe them all, and uses that cached version for later reference. With hundreds of fields and dozens of content types, rebuilding that cache of data takes longer, exacerbating the delays you're seeing on the modules page and when importing new content types.

The good news (such as it is) is that this particular issue doesn't have too much impact on the site's overall performance, just the administrative actions that flush those caches.

Answer 2

This is the same answer I made on another Drupal question; if Eaton's answer didn't solve your problem, maybe you should have a look at the Views module and dynamic menu rebuilding. Every time, the menu is rebuild, leading to 100's or even 1000's of queries. Depending on how the joins are made, you could end up with two similar joins, on the same tables, leading to doubling the number of queries. More information can be found here