Bei einem gemeinsam genutzten PHP zeigt die Homepage auf der TTFB-Seite 180 ms an. Das Team optimiert SQL-Abfragen und spart so 30 ms. Dann zeigt eine Prüfung, dass allein der Composer-Bootstrap 40 ms pro Anfrage verbraucht: Hunderte von PSR-4-Suchvorgängen, weiterhin vorhandene Entwicklungsabhängigkeiten im Produkt und ein Autoload, der nach der letzten Bereitstellung nie im optimierten Modus ausgegeben wurde.
Composer ist während der Ausführung unsichtbar. Dennoch beginnt jede HTTP-Anfrage mit „vendor/autoload.php“, das die Namespace-Zuordnung lädt und Klassen im laufenden Betrieb auflöst. Auf Laravel, Symfony oder modernem WordPress können Tausende von Dateien in die Grafik eingefügt werden – selbst wenn die Seite nur etwa zehn Dateien verwendet.
PSR-4, Classmap und was PHP wirklich lädt
Composer unterstützt mehrere Strategien:
- PSR-4: Auflösung nach Namespace → Ordner, flexibel, etwas teurer in der Ausführung.
- Classmap: umfassende Klassen-→Dateiliste, generiert von „dump-autoload“.
- Authoritative Classmap (
--classmap-authoritative): Composer greift nie auf PSR-4 zurück – Fehler, wenn eine Klasse in der Map fehlt.
| Bestellen | Wirkung | Wann |
|---|---|---|
compose dump-autoload | Regeneriert das Autoload | Nach jeder Bereitstellung |
compose dump-autoload -o | Optimierte Klassenzuordnung | Standardproduktion |
compose dump-autoload -o -a | Autorisierender Modus | Stabile Produktion, keine dynamischen Klassen |
composer install --no-dev | Entwicklerabhängigkeiten entfernen | Noch in Produktion |
Die Optimierung des automatischen Ladens bedeutet, die Anzahl der Dateisystem-Stat()-Befehle zu reduzieren, noch bevor Ihr Controller ausgeführt wird.
Entwicklungsabhängigkeiten, automatisches Laden von Dateien und unnötiger Lärm
Ein klassischer Fehler: Bereitstellung mit vollständigem „Anbieter/“, einschließlich PHPUnit, Fixtures und CI-Tools. Die Festplatte wird nicht nur größer – das automatische Laden indiziert mehr Namespaces.
Der Abschnitt „autoload“: { „files“: [...] }“ ist noch schlimmer: Diese Dateien sind bei jeder Anfrage erforderlich. Reservieren Sie es für wirklich globale Polyfills oder Helfer. Bevorzugen Sie Service-Injection oder explizite Importe.
Beim Shared Hosting ohne SSH-Zugriff verhindert eine CI-Pipeline, die „composer install --no-dev -o“ vor rsync ausführt, dass der lokale Entwickleranbieter in der Produktion bleibt.
Opcache, APCu und Invalidierung bei der Bereitstellung
OPcache speichert PHP-Bytecode zwischen – wichtig, aber getrennt vom Autoload. APCu kann die Composer-Klassenzuordnung im gemeinsam genutzten Speicher zwischen PHP-FPM-Workern verbergen.
Häufige Gefahr: Bereitstellung ohne Neustart von PHP-FPM → Worker bedienen immer noch die alte Klassenzuordnung oder eine inkonsistente Mischung. Integrieren Sie „php-fpm reload“ oder Controlled Touch nach der Anbietersynchronisierung.
Überprüfen Sie außerdem „opcache.validate_timestamps=0“ in prod (mit eigenem Redeploy), um wiederholtes stat() für Tausende von Dateien zu vermeiden – abhängig von Ihrer Veröffentlichungsrichtlinie.
Autoload und Frameworks: Laravel, Symfony, WordPress
Laravel lädt viel über Dienstleister – der Autoload Composer bleibt der erste Link. Symfony 6+ mit Flex generiert einen schlanken Autoload, aber Bundles von Drittanbietern übertreiben den Anbieter schnell.
WordPress mit Bedrock- oder Composer-Komponenten weist das gleiche Problem auf: Plugins, die ihren eigenen verschachtelten Anbieter liefern, duplizieren manchmal Pakete (Guzzle, Symfony-Komponenten) – höheres Autoload und Risiko von Versionskonflikten.
Schnelle Prüfung: „composer du“ (Duplikat) und „composer why“, um redundante Pakete zu erkennen, die entfernt werden können.
Vor der Mikrooptimierung messen
Profilieren Sie eine repräsentative Abfrage (Warenkorbseite, Admin-Dashboard). Wenn das automatische Laden > 5–10 % der CPU-Anforderungszeit beträgt, verdient der optimierte Dump die Pipeline. Andernfalls greifen Sie zuerst SQL, HTTP-Cache und Sitzungen an.
Bei lang laufenden CLI (Workers Queue) wird das Autoload nur einmal beim Booten bezahlt – das Problem betrifft hauptsächlich PHP-FPM und Request/Response-Sites.
Der Gipfel: Der Hersteller hat vom Entwickler-Laptop kopiert
Solange die Bereitstellungspipeline „install --no-dev -o“ und ein PHP-FPM-Neuladen nicht garantiert, bleibt die Optimierung des Anwendungscodes im Hinblick auf die Gesamtlatenz kosmetisch.
Entscheide dich und gehe ohne blinden Fleck voran
Fügen Sie der Pipeline „composer install --no-dev --prefer-dist -o -a“ hinzu, falls kompatibel, ein PHP-FPM-Neuladen und eine Prüfung der Autoload-„Dateien“-Einträge. Messen Sie eine repräsentative Abfrage vor und nach der Optimierung.
Um PHP-Hosting mit korrekt konfiguriertem OPcache und APCu auszuwählen, durchsuchen Sie das Verzeichnis und den Vergleich. Die Anleitungen beschreiben detailliert das PHP-Performance-Framework.
Häufig gestellte Fragen
Was macht Composer dump-autoload -o?
Es generiert eine Klassenzuordnung, die für die Auflösung von Klassen optimiert ist, ohne PSR-4 bei jeder Suche zu durchlaufen – um nach jeder Bereitstellung in der Produktion ausgeführt zu werden.
Sollten wir APCu zum automatischen Laden verwenden?
Nützlich unter gleichzeitigem PHP-FPM; Machen Sie den Cache bei der Bereitstellung durch Neuladen von FPM ungültig.
Warum das automatische Laden nicht klassifizierter Dateien vermeiden?
Der Abschnitt „Dateien“ ist in jeder Abfrage enthalten – beschränken Sie ihn auf ein Minimum.
Wie misst man die Wirkung vor der Optimierung?
Profilanfrage (Blackfire, Xdebug) oder Zeit erfordern autoload.php; Vergleichen Sie den optimierten Dump vor/nachher.
Bevor Sie einen höheren Plan erwerben, prüfen Sie eines: Ist Ihr Produktionsanbieter so schlank wie Ihr Code?