A couple of config services are initialized on every request

Is this doable in 8.0.x or should it be bumped?

Not sure :)

Do we need profiling or not?

@Wim Leers, I guess we lazy load for performance reasons. I would say Yes, but maybe @dawehner knows better.

@Wim Leers, can you provide some benchmarks?

@dawehner I have no problem to do that. I just don't know what scenario to test. It's not clear for me what page should be tested, I guess a page where the 2 services are not needed but how I determine that? Is there an inspector module that shows us what services are used on a specific page?

How I ran the benchmark:

1. Installed Drupal 8.0.x with 'standard' profile. URL: http://localhost/8/review

2. $ drush pmu -y page_cache dynamic_page_cache
   

3. $ drush cr ; sudo apachectl -k restart ; ab -n500 -c1 http://localhost/8/review
   

4. Results:
   

   Concurrency Level:      1
   Time taken for tests:   0.266 seconds
   Complete requests:      500
   Failed requests:        0
   Non-2xx responses:      500
   Total transferred:      251000 bytes
   HTML transferred:       117000 bytes
   Requests per second:    1880.71 [#/sec] (mean)
   Time per request:       0.532 [ms] (mean)
   Time per request:       0.532 [ms] (mean, across all concurrent requests)
   Transfer rate:          921.99 [Kbytes/sec] received
   
   Connection Times (ms)
                 min  mean[+/-sd] median   max
   Connect:        0    0   0.0      0       1
   Processing:     0    0   2.6      0      57
   Waiting:        0    0   2.6      0      57
   Total:          0    1   2.6      0      58
   

5. Applied the patch from #3

6. $ drush cr ; sudo apachectl -k restart ; ab -n500 -c1 http://localhost/8/review
   

7. Results:
   

   Concurrency Level:      1
   Time taken for tests:   0.260 seconds
   Complete requests:      500
   Failed requests:        0
   Non-2xx responses:      500
   Total transferred:      251000 bytes
   HTML transferred:       117000 bytes
   Requests per second:    1921.43 [#/sec] (mean)
   Time per request:       0.520 [ms] (mean)
   Time per request:       0.520 [ms] (mean, across all concurrent requests)
   Transfer rate:          941.95 [Kbytes/sec] received
   
   Connection Times (ms)
                 min  mean[+/-sd] median   max
   Connect:        0    0   0.0      0       0
   Processing:     0    0   2.3      0      51
   Waiting:        0    0   2.3      0      51
   Total:          0    0   2.3      0      51
   

So HEAD has 1880.71 (±2.6) vs. #3 that is 1921.43 (±2.3). Even if looks like a relevant delta, I'm not so sure that the difference is so big. But, anyway, at least we know that #3 is not a performance regression.

I'm passing this to @dawehner for review.

@dawehner, does this issue need anything else?

OK.

Yay!

I'm not sure I believe the benchmarks in #12. If we have 0.5ms response then Drupal 8 has got significantly faster.

Given the results below I'm not sure that there is much of a boost here... comparing first runs shows a boost but the second run without the patch is as fast as with the patch.

Without patch

Concurrency Level:      1
Time taken for tests:   53.803 seconds
Complete requests:      500
Failed requests:        0
Total transferred:      8493000 bytes
HTML transferred:       8242500 bytes
Requests per second:    9.29 [#/sec] (mean)
Time per request:       107.607 [ms] (mean)
Time per request:       107.607 [ms] (mean, across all concurrent requests)
Transfer rate:          154.15 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:    89  107 101.1     99    1906
Waiting:       80   97  99.3     89    1848
Total:         89  108 101.1     99    1906

Percentage of the requests served within a certain time (ms)
  50%     99
  66%    101
  75%    102
  80%    103
  90%    106
  95%    112
  98%    122
  99%    149
 100%   1906 (longest request)

On second run...

Requests per second:    9.49 [#/sec] (mean)
Time per request:       105.319 [ms] (mean)
Time per request:       105.319 [ms] (mean, across all concurrent requests)
Transfer rate:          157.50 [Kbytes/sec] received

With patch

Concurrency Level:      1
Time taken for tests:   52.767 seconds
Complete requests:      500
Failed requests:        0
Total transferred:      8493000 bytes
HTML transferred:       8242500 bytes
Requests per second:    9.48 [#/sec] (mean)
Time per request:       105.534 [ms] (mean)
Time per request:       105.534 [ms] (mean, across all concurrent requests)
Transfer rate:          157.18 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    91  105  89.5     98    1868
Waiting:       82   95  87.7     89    1812
Total:         91  105  89.5     98    1869

Percentage of the requests served within a certain time (ms)
  50%     98
  66%    100
  75%    101
  80%    102
  90%    105
  95%    113
  98%    124
  99%    155
 100%   1869 (longest request)

On second run

Requests per second:    9.49 [#/sec] (mean)
Time per request:       105.335 [ms] (mean)
Time per request:       105.335 [ms] (mean, across all concurrent requests)
Transfer rate:          157.48 [Kbytes/sec] received

Well spotted, Alex. 0.5 ms is even faster than page cache. I was gonna say "concurrency higher than 1", but that's also not the case. Not sure what #12 tested then, but it's definitely not Drupal.

This should get actual profiling, using XHProf. The numbers in #19 may be skewed also, because DB I/O has a higher variance that can easily obscure this.

@Wim Leers. The explanation has been provided by @Berdir on IRC:

Non-2xx responses:      500

It seems that there was an error (500 or something else) while ran the benchmark. I didn't pay attention to that line.

Yes, wee need to profile and see function calls, etc.

Here's the profiling.

HEAD cold

HEAD warm

Patch cold

Patch warm

Looks like a small regression.

EDIT: I repeated several times the whole scenario but the deltas were more or less the same.

What profiling tool is this? It's definitely not XHProf's default UI.

@Wim Leers, I installed xhprof on my Mac $ brew install homebrew/php/php55-xhprof. Then I enabled the https://www.drupal.org/project/xhprof module.

Hmmm using a module to generate XHProf data is not really the best way. Here's a warm cache compared with and without the patch where the Xhprof code is added by Apache. The test was the frontpage standard with no content and the anonymous user. I repeat the runs with and without the patch until the number of functions calls remains the same.

Well, #25, shows some progress in terms of response time even function calls and memory are increasing. But the time is what concerns us, right?

Now what?

Stumbled over this. Did some checks with blackfire, config managed does not show up, with enabled or disabled page cache.

I suspect that was related to config entities and setting their values, we've removed the runtime dependency on typed config/config schema for that a long time ago.

I do see some possibly micro-optimizations, like putting the default timezone into the container similar to how we handle the default language, but that's not related to this.