Op een gedeelde PHP geeft de startpagina 180 ms aan de TTFB-kant weer. Het team optimaliseert SQL-query's, waardoor 30 ms wordt bespaard. Vervolgens blijkt uit een audit dat alleen al de Composer-bootstrap 40 ms per verzoek verbruikt: honderden PSR-4-lookups, dev-afhankelijkheden die nog steeds aanwezig zijn in prod, en een autoload die na de laatste implementatie nooit in de geoptimaliseerde modus is gedumpt.
Composer is onzichtbaar terwijl het actief is. Toch begint elk HTTP-verzoek met vendor/autoload.php, dat de naamruimtetoewijzing laadt en klassen direct oplost. Op Laravel, Symfony of moderne WordPress kunnen duizenden bestanden in de grafiek terechtkomen, zelfs als de pagina er maar een stuk of tien gebruikt.
PSR-4, classmap en wat PHP echt laadt
Composer ondersteunt verschillende strategieën:
- PSR-4: resolutie per naamruimte → map, flexibel, iets duurder in gebruik.
- Classmap: uitgebreide klasse → bestandslijst, gegenereerd door
dump-autoload. - Authoritatieve classmap (
--classmap-authoritative): Componist valt nooit terug op PSR-4 — fout als klasse ontbreekt op de kaart.
| Bestel | Effect | Wanneer |
|---|---|---|
compose dump-autoload | Regenereert de autoload | Na elke implementatie |
compose dump-autoload -o | Geoptimaliseerde klassenkaart | Standaardproductie |
compose dump-autoload -o -a | Gezaghebbende modus | Stabiele productie, geen dynamische klassen |
componist install --no-dev | Ontwikkelaarsafhankelijkheden verwijderen | Nog steeds in productie |
Het optimaliseren van autoload betekent het verminderen van het aantal bestandssysteemstat() zelfs voordat uw controller wordt uitgevoerd.
Ontwikkelaarsafhankelijkheden, bestanden automatisch laden en onnodige ruis
Een klassieke fout: implementeren met volledige vendor/ inclusief PHPUnit, armaturen en CI-tools. Niet alleen wordt de schijf groter; er worden automatisch indexeert meer naamruimten geladen.
De sectie "autoload": { "files": [...] } is nog erger: deze bestanden zijn vereist bij elk verzoek. Reserveer het voor echt mondiale polyfills of helpers. Geef de voorkeur aan service-injectie of expliciete import.
Op gedeelde hosting zonder SSH-toegang voorkomt een CI-pijplijn die composer install --no-dev -o uitvoert vóór rsync dat de lokale ontwikkelaarleverancier in productie blijft.
Opcache, APCu en invalidatie bij implementatie
OPcache cachet PHP-bytecode — essentieel, maar gescheiden van automatisch laden. APCu kan de Composer-klassekaart verbergen in gedeeld geheugen tussen PHP-FPM-werkers.
Veelvoorkomende valkuil: implementeren zonder PHP-FPM opnieuw te starten →workers bedienen nog steeds de oude klassenmap of een inconsistente mix. Integreer 'php-fpm reload' of gecontroleerde aanraking na leverancierssynchronisatie.
Controleer ook opcache.validate_timestamps=0 in prod (met eigen herimplementatie) om herhaalde stat() op duizenden bestanden te voorkomen — afhankelijk van uw releasebeleid.
Autoload en raamwerken: Laravel, Symfony, WordPress
Laravel laadt veel via serviceproviders – de Autoload Composer blijft de eerste link. Symfony 6+ met flex genereert een gestroomlijnde autoload, maar bundels van derden verhogen de leverancier snel.
WordPress met Bedrock- of Composer-componenten ervaart hetzelfde probleem: plug-ins die hun eigen geneste leverancier leveren, dupliceren soms pakketten (Guzzle-, Symfony-componenten) - zwaardere autoload en risico op versieconflicten.
Snelle audit: composer du (duplicaat) en composer waarom om overtollige pakketten op te sporen die kunnen worden verwijderd.
Meet vóór micro-optimalisatie
Profileer een representatieve zoekopdracht (mandpagina, beheerdersdashboard). Als automatisch laden > 5-10% van de CPU-verzoektijd bedraagt, verdient de geoptimaliseerde dump de pijplijn. Val anders eerst SQL, HTTP-cache en sessies aan.
In langlopende CLI (werknemerswachtrij) wordt de autoload slechts één keer betaald tijdens het opstarten. Het probleem ligt voornamelijk bij PHP-FPM en verzoek/antwoord-sites.
De top: de leverancier heeft gekopieerd van de ontwikkelaarslaptop
Zolang de implementatiepijplijn geen install --no-dev -o en een PHP-FPM-herlaadbeurt garandeert, blijft het optimaliseren van de applicatiecode cosmetisch in termen van algehele latentie.
Beslis en ga vooruit zonder blinde vlek
Voeg aan de pijplijn composer install --no-dev --prefer-dist -o -a toe indien compatibel, een PHP-FPM herlaadbeurt en een audit van de automatisch geladen files-items. Meet een representatieve vraag voor en na de optimalisatie.
Om PHP-hosting te kiezen met OPcache en APCu correct geconfigureerd, bladert u door de map en de vergelijking. De gidsen beschrijven het PHP-prestatieframework.
Veelgestelde vragen
Wat doet composer dump-autoload -o?
Het genereert een klassenmap die is geoptimaliseerd voor het oplossen van klassen zonder bij elke zoekopdracht PSR-4 te hoeven doorlopen – om na elke implementatie in productie te worden uitgevoerd.
Moeten we APCU gebruiken voor automatisch laden?
Handig onder gelijktijdige PHP-FPM; maak de cache ongeldig bij implementatie via FPM opnieuw laden.
Waarom het automatisch laden van niet-geclassificeerde bestanden vermijden?
De sectie 'bestanden' is bij elke zoekopdracht inbegrepen; houd deze minimaal.
Hoe meet je de impact voordat je gaat optimaliseren?
Profielverzoek (Blackfire, Xdebug) of tijd vereist autoload.php; vergelijk voor/na geoptimaliseerde dump.
Voordat u een hoger plan aanschaft, moet u één ding controleren: is uw productieleverancier net zo lean als uw code?