Hi!

Chx asked me to open a ticket for this issue. I read the news about the release of Drupal 6 on Goba's blog, and one sentence was strange for me. In the code optimization block it is stated that the code is separated into multiple files and only that code is included which is needed.

But this approach has a negative impact on performance, because it is true only if there is no opcode cache. But an opcode cache will be installed on a system where performance is an issue. And if opcode cache is presented it worth to include fewer times and in bigger chunks of code.

I did some tests on this topic, I try to get the results and post is here (it is on my previous workplace's wiki).

Best Regards,
Felhő

Comments

kbahey’s picture

kbahey commented

There are two cases:

1. Without an op-code cache:

This is the most common case on shared hosts.

Loading, parsing, and tokenizing less code on each page view provides a performance benefit in speed, as well as lower memory usage, which shared hosts do seem to enforce for some time.

There were benchmarks published for this patch, and they show benefits.

2. With an op-code cache:

The code is cached anyway, and this new feature has no impact on performance, positive or negative.

Crell’s picture

Crell commented

It's really a balance. Every file stat costs time. Every function that must be parsed costs time. In Drupal 5, we simply parsed everything, 80%+ of which we didn't actually need. In Drupal 6, we've split off the easiest-to-skip code at the cost of one extra file stat. Early benchmarks suggested it should be a big win, but I still have to do final benchmarks. Assuming it's as useful as we suspect it was, Drupal 7 should have a more advanced mechanism that we can use to further optimize that balance.

felho’s picture

felho commented

Hi!

No opcode cache: I think this is not an important case while anywhere if the performance is an issue the minimum is that an opcode cache is installed. And I don't think that this kind of memory usage saving is considerable (but I have never tested it).

But the I did more tests with this splitting issue (relating to speed performance), while I was working on a site with 70-80 million hit/day (only the public site, and much more gateway calls). The page has 9 files (logically separated codes) which was loaded by a bootstrap file. I tried to load each after the other, and then I copied theme into one file, and included this file.

Without opcode cache the splitting was absolutely winner, but with opcode cache loading the files separately was 300% while loading theme in one step was 100%. Of course this is a relative time, maybe this impact only a little part of the full request, but it was absolutely measurable and fix difference. And things betting much worse when I run the test on a heavily loaded server (part of the previously mentioned cluster) and the difference was much higher (700%) thanks to the higher IO load. (It is not negligible if you make your test in an environment which is close in its characteristic to the production one, in this case for example the IO load has big impact on the results you will get.)

This is my experience on the topic, I hope I can help.

Best Regards,
Felhő

Crell’s picture

Crell commented
Status: Postponed (maintainer needs more info) » Fixed

I think I can definitely say yes, it is worth it: http://www.garfieldtech.com/blog/benchmark-page-split

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.