-1

We have a site with performance issues. And we are looking for advice on low hanging fruit or other strategies that can have a dramatic increase on performance.

The seemingly obvious culprit is massive module bloat with a total of 175 enabled modules. We are aware that this is an architectural flaw however we are not in a position to spend the amount of time necessary to resolve that in any big way. Most of the modules contributing to this bloat are contrib modules.

  • We are using memcache for caching and also making use of APC.
  • We have already identified so slow DB queries and re engineered some views to get an improvement here.
  • We have tuned view and block caching through the site.

We have also applied a few of the common performance and scalability modules including - entity cache - Cache expiration - Cache actions.

Due to other architectural considerations (a 3rd party product working as a reverse proxy) we are not in a position to utilise varnish in a very useful capacity.

The average time out of 5 calls via wget (with a cache clear before each before each call) is about 42.182 seconds on a dev instance. The average time out of 5 calls via wget (with a warm cache) is about 9.43 seconds on a dev instance.

We experience similar slow performance on the staging server. That server also serves a few staging instances of other sites that perform decently. Our sysadmins have configured the databases here so I do not consider the database configuration to be a likely cause of much of our performance issues.

If anyone has experience improving the performance of Drupal sites with large module boat you input is most welcome.

0

Did you try boost module? If you have mostly anonymous traffic this is really a good start.

Additionally apart from block caching do you use the visibility settings per block when a block is not visible on all pages? My experience from many projects is that many times regions are simply not printed on templates and people think the blocks are not rendered because you do not see them. If you do not use the visibility settings to avoid block rendering every block is rendered on every page request which can lead to an enormous overhead.

Addionally depending on the view I realized that sometimes it gains better performance to use custom queries and page callbacks to render a result page instead of using the views module.

What often leads to big queries is the fields API with all these joins. For every field two tables with much data are created which is often not neccessarry. Therefore I started to use Entity API more often to decribe custom data structures instead of using nodes and content types with fields for that.

  • Hey Tobias, thanks. We are most definitely making use of the boost module. However the 3rd party reverse proxy the vast majority of users moving forward will be authenticated. I have today identified on one page a view a heavy view and I'm now going to dive in and analyse the SQL it generates. It may mean recreating that view. I'm going to look into the visibility settings on the blocks, excellent tip thanks. – Thursday Aug 12 '14 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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