summary: we need to fix config caching.
here is some lulz-inducing stuff from Berdir:
"Started looking into the preload issue and found some things that need to be fixed in the config override code. No specific order and not everything is equally problematic but there are some pretty serious performance regressions, so setting to critical for now.
a) Trivial and easy to fix performance problem. DrupalKernel::initializeContainer() calls $factory->get('system.module')->load()->get('enabled'), the explicit load() does an unconditional call to $cached_storage->read() but the config has already been loaded by the config factory at that point. As discussed with @beejebus, maybe load() should be protected but that seems like a separate issue to figure out.
b) Fixing that, I noticed that ConfigFactory/CachedStorage isn't good at dealing with non-existing config files. color.module tries to load a non-existing color.bartik (might be a bug on it's own), then fun things happen:
3. CachedStorage::loadMultiple(array('color.bartik', 'language.config.en.color.bartik'))
4. Cache miss on both of them.
5. FileStorage::readMultiple() => read() for both of them, still not existing.
6. Back to CacheFactory::get(), loadMultiple() did not return anything, so we go into the else
7. CachedStorage::read('language.config.en.color.bartik') ($this->storage->read($this->getLanguageConfigName($this->language->id, $name)); => that config file name helper method can return FALSE!?)
8. another cache miss, another attempt to load the file from FileStorage, obviously another fail :)
9. So no config and no overrides (suprise! ;)), we return an empty config object, but this is not the end, all good things are 10 ;)
10. Now color.module calls get('load'), that somehow thinks that it hasn't been loaded yet and just to be sure tries to load color.bartik again. So another failed cache get, another call to FileStorage. I don't see why we still have the lazy-load implementation inside Config if we pre-load everything again?
Conclusion: Trying to load a single non-existing config file results in 4 cache misses and 4 FileStorage::read() calls.
Suggestion: Apart from trying to clean that mess (sorry :)) up, we need to keep track of non-existing files in CachedStorage, maybe in a single cache?
c) Note that creating a new config file (e.g. saving a new config entity) goes through the same chain right now, this is something that whatever missing-config files cache we will have in CachedStorage needs to somehow being able to handle this, so a save() needs to make sure to update that information.
d) It also applies, even though not quite as severe ("just" a single cache miss + FileStorage::read()) to every single non-existing language override config file read(). See above about needing an efficient non-existing config object cache.
e) And lastly, I'm wondering why we're even trying to load language overrides on my system at all, because this is not a multilingual installation. We can skip the language overrides completely if languageManager->isMultilingual() is FALSE and we might be able to optimize more there but that is going to be a bit more complicated (config entity objects all have a langcode, we don't need to look for overrides if that matches the current language or if it doesn't have such a key and we are using the default language?)"
PASSED: [[SimpleTest]]: [MySQL] 63,368 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 63,249 pass(es). View