[6.2] Extreme Probleme mit der Performance des ClassLoaders

Hi,
heute ist eine Webseite live gegangen, an der ich gearbeitet habe.
Leider ist die Performance deutlich schlechter als im Testbetrieb. Den Grund dafür konnte ich nach ca. 1 Tag Profiling aber auch feststellen.

Leider war der Kunde nicht bereit, das System noch vor dem Livegang von 6.2 auf 7.6 upzudaten. Dementsprechend müssen wir jetzt mit dem schlichtweg kaputtem Caching-Framework von 6.2 leben. Mit jeder anderen Einstellung für cache_core und cache_classes als den folgenden beiden gibt es einige Errors "class not found", weil dann die Migrations von Tx_Vendor_Kategorie_Klasse zu \Vendor\Kategorie\Klasse (Namespaces) nicht beachtet werden:

$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_core']['backend'] = 'TYPO3\CMS\Core\Cache\Backend\NullBackend';
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_classes']['backend'] = 'TYPO3\CMS\Core\Cache\Backend\TransientMemoryBackend';

Damit sind die Caches für cache_core und cache_classes de facto deaktiviert.

Damit liefen Tests dennoch akzeptabel. Apache Benchmark mit 50 concurrent Usern immer noch knapp 1 s TTFB auf den meisten Seiten. Wir verwenden Redis für die anderen Caches wie z.B. cache_pages, wenn möglich.

Das Problem jetzt im Live-Betrieb ist allerdings bisher noch nicht aufgetreten:

• TTFB zwischen 8 und 12 s
• XDebug Profiling ergibt 70% der Laufzeit in php::usleep()
• php::usleep wird aufgerufen von ClassLoader::acquireExclusiveLock()
• wird wiederum aufgerufen wenn die einzelnen Klassen der Extensions etc. geladen werden müssen

Im jeweiligen Code des ClassLoaders wird klar, dass immer die "simple" Locking-Methode zum Laden von gecacheten Klassen verwendet wird (php::fopen() wird auf FALSE gecheckt).
Das ist mehrmals (ca. 30-40 mal) nicht erfolgreich. Danach schläft der Prozess für 200ms jedes mal, so kommen die usleep-Zeiten zustande.

Was ich mich jetzt frage, ist, warum die betreffenden Klassendateien überhaupt so oft/lange gelockt sind? Haben wir zu schwache Server-Resourcen (8 Kerne eines AMD Opteron 6276, 32 GB RAM, SSD, Apache 2.4 mod_event, PHP-FPM 5.6 mit relativ hohen Child-Prozess-Limits)?

Und warum wird überhaupt versucht auf gecachete Klassen-Dateien zuzugreifen? NullBackend sagt explizit "kein Cache". TransientMemoryBackend sagt "Cache, aber nur in diesem einem Prozess im RAM", also quasi kein Cache.

Wo ist mein Fehler?

Danke schonmal, falls einer helfen kann.
Grüße