Da viele der einzelnen Komponenten eng miteinander verzahnt sind, liegt es in der Natur der Sache, dass die Ursache für einen Flaschenhals nicht immer offensichtlich ist. Als Beispiel sei ein Performance-Engpass im zentralen Filesystem genannt. Jede „require()“-Funktion braucht dadurch wenige Millisekunden länger, was sich schnell aufsummiert. Als Symptom zeigt sich eine erhöhte CPU-Auslastung auf den Webservern, die mit der eigentlichen Ursache jedoch nichts zu tun haben.

Skalierungsproblem Datenbank

Wie oben beschrieben, ist es sehr einfach möglich, weitere Webserver in das System aufzunehmen. Bei der MySQL-Datenbank ist das nicht so ohne Weiteres möglich, da alle Webserver auf den gleichen Datenbank-Server zugreifen. Ab einer gewissen Menge von Anfragen skaliert MySQL auf einer Standard-Hardware nicht mehr mit. Jetzt bringen auch noch mehr und noch schnellere CPUs und mehr RAM nichts mehr. TYPO3 sollte daher von vornherein nicht mit persistenten Datenbankverbindungen arbeiten, zu erreichen durch „$TYPO3_CONF_VARS['SYS']['no_pconnect'] = 1;“.

Dadurch baut PHP zwar ständig neue Verbindungen auf, diese verschwinden jedoch nach Abarbeitung des Skripts wieder aus dem Connection-Pool der Datenbank. MySQL muss daher weniger Connections verwalten als mit persistenten Verbindungen. Die Webserver können die auf ihrer Seite entstehenden zusätzlichen Befehle gut bewältigen.

Mittlerweile gibt es durch Replikationsmechanismen, so genannte „Read-Only Slave“- oder „Master-Master“-Konfigurationen, und durch die MySQL-Cluster-Engine (NDB) mehrere Lösungen, die das Verfügbarkeits- und Skalierungsproblem auf Datenbankseite zu lösen versuchen. In der Praxis zeigt sich jedoch sehr schnell, dass beide Lösungen mit Nachteilen behaftet sind, die einen Einsatz in einem Websystem überdenkenswert erscheinen lassen.