Die Scaling-Checkliste, die die meisten PHP-Teams überspringen

Ein Scaling-Problem tritt nahezu nie als einzelnes dramatisches Versagen auf. Es tritt als langsame, zunehmend sichtbare Ansammlung kleiner Probleme auf: Antwortzeiten, die schleichend steigen, Cron-Jobs, die länger laufen als die Fenster es erlauben, das Staging-Umfeld, das sich weigert zu seeden, weil das Dataset zu groß ist, das Deployment, das früher drei Minuten dauerte und jetzt neunzehn, der Bereitschaftsengineer, der mehr Wochenenden damit verbringt, dem CEO Dinge zu erklären, als im Code Dinge zu reparieren.

Wenn das Scaling-Gespräch das Leadership-Team erreicht, hat das Team meistens bereits die offensichtlichen Schritte probiert. Sie haben Redis hinzugefügt. Sie haben Sessions aus der Datenbank herausgezogen. Sie haben Cloudflare davorgestellt. Sie haben die PHP-FPM-Worker-Zahl erhöht. Keiner dieser Schritte ist direkt falsch. Sie sind nur nicht die Schritte, die Scaling tatsächlich erfordert, und sie kaufen drei Wochen Erleichterung, bevor dieselben Symptome zurückkommen, jetzt zusätzlich mit einem Redis-Cluster zu warten.

Dieser Essay ist eine Checkliste. Keine Liste trendiger Patterns. Keine Liste von Services, die Sie adoptieren sollten. Neun Punkte, in der Reihenfolge, in der ich sie in einer typischen PHP/Symfony-Anwendung angehen würde, die aus ihrer ersten Architektur herausgewachsen ist und ehrlich sein muss, was als Nächstes kommt.

Ich habe sie danach gerankt, wie oft Teams zu wenig in sie investieren, wobei der Spitzenreiter die Arbeit ist, die am meisten zurückzahlt und am häufigsten übersprungen wird.

#1. Machen Sie die Datenbank langweilig, bevor Sie irgendetwas anderes tun

Der mit Abstand wirkungsvollste Scaling-Schritt in jeder PHP-Anwendung ist, die Datenbank langweilig zu machen. Langweilig heißt: vorhersagbare Query-Patterns, ein Index für jeden heißen Pfad, keine überraschenden Sequential Scans und keine impliziten N+1-Patterns, die sich hinter Doctrine-Relations verstecken.

Die meisten Teams überspringen das, weil sich die Datenbank erst langsam anfühlt, wenn sie es ist, und wenn sie es ist, sind die Kosten, die Patterns zu reparieren, viel höher als sie es sechs Monate früher gewesen wären. Die Lösung: Slow-Query-Analyse zu einem wöchentlichen Ritual zu machen, nicht zu einer Incident-Response.

Die minimal tragfähige Instrumentierung:

# config/packages/doctrine.yaml
doctrine:
    dbal:
        profiling: '%kernel.debug%'

# config/packages/monolog.yaml (prod)
monolog:
    handlers:
        slow_queries:
            type: stream
            path: '%kernel.logs_dir%/slow_queries.log'
            level: info
            channels: ['doctrine']

Kombinieren Sie das mit pg_stat_statements (oder dem MySQL Slow Query Log), aktiviert in Produktion, und schauen Sie sich einmal pro Woche die Top zwanzig Queries nach Gesamtzeit an. Nicht die langsamsten Queries. Die Queries, die über alle Aufrufe hinweg die meiste kumulative Zeit verbrauchen. Das sind nahezu immer die, die einen Index brauchen, nicht die, die einmal am Tag 800ms dauern.

Auf der Applikationsseite: Auditieren Sie Ihre Doctrine-Fetch-Joins. Das Pattern, das die meisten Symfony-Apps unter Skalierung killt, ist ein Controller, der eine paginierte Liste holt und pro Zeile drei Relations lazy lädt. Zwanzig Zeilen pro Seite, vier Queries pro Zeile, und Sie sind bei 80 Queries pro Request, bevor Sie irgendeine eigentliche Arbeit erledigt haben. Reparieren Sie das mit expliziten addSelect()- und join()-Aufrufen in Ihren Repositories und schreiben Sie einen Test, der Query-Counts auf den heißen Endpoints überprüft.

#2. Identifizieren Sie Ihre drei langsamsten Endpoints und instrumentieren Sie sie richtig

Die meisten Teams wissen tatsächlich nicht, welche Endpoints in Produktion langsam sind. Sie wissen, welche Endpoints sich langsam anfühlen, wenn sie in Staging herumklicken. Das ist nicht dasselbe.

Richten Sie echte Per-Endpoint-Metriken ein. Das minimal Akzeptable ist:

• p50-, p95-, p99-Latency pro Route, pro Methode
• Fehlerrate pro Route
• Request-Count pro Route

Tools, die Sie günstig dorthin bringen: Symfonys eingebauter Profiler (nur Development), blackfire/blackfire-php-sdk für Production-Sampling, ein OpenTelemetry-Exporter, der ein Backend bedient, das Sie bereits nutzen (Datadog, Grafana Cloud, Honeycomb). Das Tool ist weniger wichtig als die Disziplin, wöchentlich auf die Zahlen zu schauen.

Sobald Sie die Daten sehen, ist die Regel einfach: Optimieren Sie nicht den Endpoint, der sich langsam anfühlt, sondern den Endpoint, der über alle Benutzer hinweg die meiste aggregierte Zeit verbraucht. Ein 200ms-Endpoint, der eine Million Mal pro Tag aufgerufen wird, ist ein deutlich größerer Hebel als ein 8-Sekunden-Endpoint, der zweimal aufgerufen wird.

#3. Cachen Sie das Richtige, nicht das Einfache

Nahezu jedes Team, mit dem ich arbeite, hat einen Redis-Cluster. Nahezu kein Team nutzt ihn für die richtigen Dinge.

Die richtigen Dinge zum Cachen, in der Reihenfolge des Hebels:

1. HTTP-Responses mit einem echten Cache Key. Symfonys HTTP-Cache (oder ein vorgeschaltetes Varnish oder der eingebaute EsiResponseListener für Fragmente) auf Routen, die ein 60-Sekunden-TTL tolerieren können. Das ist der höchste Hebel und wird am häufigsten übersprungen, weil “wir eine App mit Login haben”. Die meisten Apps mit Login haben trotzdem quasi-öffentliche Routen (Marketing-Seiten, öffentliche Profile, Suchergebnisse ohne Filter), die sich mit private=false und einem tenant-bewussten Key HTTP-cachen lassen.
2. Berechnete Read Models. Muss ein Request über fünf Tabellen aggregieren, um ein Dashboard-Widget zu rendern, cachen Sie die resultierende Struktur für 30 Sekunden. Verwenden Sie ein Write-Through-Pattern (invalidieren, wenn sich Quelldaten ändern) nur, wenn die Konsistenzanforderung es tatsächlich verlangt, für analytik-artige Reads reicht ein TTL nahezu immer.
3. Teure Drittanbieter-Aufrufe. Externe APIs, die Sie nicht kontrollieren, sind der schlechteste Ort auf einem heißen Pfad. Cachen Sie aggressiv, mit Circuit Breakers um die Cache Misses.

Die falschen Dinge zum Cachen, in der Reihenfolge, wie stark sie Sie verbrennen:

1. Doctrine-Query-Ergebnisse ohne strikte Invalidierungsstrategie. Doctrines Second-Level Cache funktioniert in der Theorie, schmerzt in der Praxis bei den meisten Anwendungen. Die Invalidierungsregeln sind subtil und der Fehlermodus ist “Benutzer sehen veraltete Daten, die sie nicht erklären können”.
2. Cache-Wrapper über Cache-Wrapper. APCu vor Redis vor Doctrine. Jede Schicht fügt einen weiteren Ort hinzu, an dem der Cache falsch sein kann. Wählen Sie eine Schicht pro Anliegen.
3. Alles, was Sie bei Bedarf nicht explizit invalidieren können. Ist der einzige Weg, den Cache zu leeren, ganz Redis zu flushen, haben Sie ein Debugging-Problem gebaut, keine Performance-Lösung.

#4. Verlagern Sie langlaufende Arbeit in eine Queue, mit dem richtigen Transport

Das ist der Schritt, in den Teams reflexhaft zu wenig investieren. Sie sagen immer wieder “wir verlagern es in eine Queue, wenn es ein Problem wird”, und dann wird es an einem Freitagnachmittag während eines Launches zum Problem.

Die Arbeit, die in eine Queue gehört, ist alles, was:

• eine externe API auf dem Request-Pfad aufruft
• eine E-Mail versendet
• ein PDF generiert oder ein Bild verarbeitet
• mehr als ein paar Zeilen in einer Transaktion aktualisiert
• bei Fehler sicher wiederholt werden kann

In Symfony 7.4 bringt Messenger Sie den größten Teil des Weges. Der Fehler, den Teams machen: zu lange nach sync:// zu greifen, weil “wir sind ein kleines Team”. Die Form Ihres Codes sollte message-basiert sein, auch wenn der Transport sync ist, denn das spätere Umstellen ist mechanisch, während Code, der sich auf synchrone Aufrufe verlässt, in asynchrone Messages zu konvertieren, es nicht ist.

Eine vernünftige Ausgangs-Transport-Konfiguration:

framework:
    messenger:
        transports:
            async_low:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    queue_name: low
                retry_strategy:
                    max_retries: 5
                    multiplier: 3
            async_high:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    queue_name: high
                retry_strategy:
                    max_retries: 3
                    multiplier: 2
            failed:
                dsn: 'doctrine://default?queue_name=failed'

        failure_transport: failed

        routing:
            'App\Messenger\Async\Low\\': async_low
            'App\Messenger\Async\High\\': async_high

Die Aufteilung auf zwei Queues (low und high) ist der Teil, den die meisten Teams überspringen. Sie ist wichtig, weil in dem Moment, in dem Sie eine einzelne Queue haben, eine Flut von Low-Priority-Messages (Willkommens-E-Mails, Analytics-Events) die High-Priority-Messages (Password-Resets, Zahlungsbestätigungen) blockiert. Das Aufteilen kostet nichts und bewahrt Sie vor der schlimmsten Klasse von Incidents.

Wählen Sie einen echten Broker (RabbitMQ, Amazon SQS, Redis Streams), bevor Sie müssen. Der Doctrine-Transport ist in Ordnung für Development und die Failed Queue, aber er skaliert nicht auf die Volumina, die eine ausgelastete Produktionsanwendung erzeugt.

#5. Hören Sie auf, wie 2016 zu deployen

Ist Ihr Deployment “SSH rein, git pull, composer install --no-dev, bin/console cache:clear, PHP-FPM neustarten”, haben Sie eine Skalierungsgrenze, die nichts mit Traffic zu tun hat.

Das minimal akzeptable Deployment für eine produktive PHP-Anwendung:

• Bauen Sie in CI ein deploybares Artefakt (ein Tarball oder ein Container Image) mit allen installierten Abhängigkeiten und vorgewärmtem Cache.
• Deployen Sie durch Umschalten eines Symlinks (mit deployer/deployer) oder durch Rollout eines Container Images (mit Kubernetes oder ECS), nicht durch Mutation des laufenden Verzeichnisses.
• Führen Sie Datenbank-Migrations als separaten, expliziten Schritt aus, nicht als Teil des Application-Boots.
• Rollen Sie das Deployment über Instanzen hinweg, nicht alle auf einmal. Auch wenn Sie zwei Instanzen haben, deployen Sie sie sequenziell mit einem Health Check dazwischen.

Das ist unter Skalierung wichtig, weil das nächste Problem, das Sie treffen werden, nachdem Datenbank und Queues repariert sind, darin besteht, dass Sie nicht häufig genug deployen können, um mit den Änderungen Schritt zu halten, die das Team ausliefern muss. Ein Deployment, das 19 Minuten dauert und fehlschlagen könnte, wird einmal pro Tag erledigt, an einem guten Tag. Ein Deployment, das 90 Sekunden dauert und sich durch erneutes Deployen des vorherigen Builds rückgängig machen lässt, wird sechsmal pro Tag erledigt, was heißt: jedes Deployment trägt weniger Änderung, was heißt: weniger Risiko pro Deployment, was heißt: mehr Deployments. Die gesamte Schleife zieht sich zusammen.

#6. Machen Sie Session-Storage zum Problem von jemand anderem

Symfonys standardmäßiger dateibasierter Session-Storage funktioniert wunderbar auf einem einzelnen Server und fällt in dem Moment auseinander, in dem Sie einen zweiten hinzufügen. Sticky Sessions auf dem Load Balancer sind die falsche Lösung, sie machen Ihr Scaling-Problem nur unsichtbar, bis Sie eine Instanz für Wartung aus dem Pool nehmen müssen und feststellen, dass 30% Ihrer aktiven Benutzer daran gepinnt sind.

Verlagern Sie Sessions zu Redis. Verwenden Sie den RedisSessionHandler und konfigurieren Sie ihn explizit:

framework:
    session:
        handler_id: 'redis_session_handler'
        cookie_secure: auto
        cookie_samesite: lax
        gc_maxlifetime: 1209600 # 14 days

services:
    redis_session_handler:
        class: Symfony\Component\HttpFoundation\Session\Storage\Handler\RedisSessionHandler
        arguments:
            - '@Redis'
            - { prefix: 'app:session:', ttl: 1209600 }

    Redis:
        class: Redis
        calls:
            - connect: ['%env(REDIS_HOST)%', '%env(int:REDIS_PORT)%']

Zwei Hinweise, die Teams erwischen:

• Die Session ist ein heißer Key. Jeder authentifizierte Request liest und schreibt sie. Stellen Sie sicher, dass Ihr Redis dafür dimensioniert ist, und erwägen Sie eine separate Redis-Instanz für Sessions versus Cache, damit das Flushen der einen nicht die andere tötet.
• Anders als der native PHP-Datei-Handler führt der RedisSessionHandler kein Session-Locking durch, was bedeutet, dass konkurrierende Writes racen können (das klassische Symptom ist ein fälschlicher “Invalid CSRF token”, wenn zwei AJAX-Requests gleichzeitig feuern). Entweder halten Sie Session-Writes auf Ihren heißen Pfaden idempotent, oder Sie wickeln die kritischen Abschnitte in einen Redis-Lock. Benötigen Sie native Locking-Semantik auf einem relationalen Store, unterstützt PdoSessionHandler LOCK_TRANSACTIONAL auf Zeilenebene.

#7. Observability hinzufügen, bevor Sie sie brauchen

Wenn das Produktionsproblem eintrifft, haben Sie keine Zeit zu instrumentieren. Sie haben Zeit, bereits existierende Graphen zu lesen, und Zeit, bereits geschriebene Logs zu greppen, und das war’s.

Die vier Dinge, die jede produktive PHP-Anwendung braucht, bevor sie eine Million Requests pro Tag überschreitet:

1. Structured Logging. Jede Logzeile ist JSON, mit mindestens: Timestamp, Level, Channel, Nachricht, Context-Objekt, request_id, user_id (oder null). Monolog mit dem JSON-Formatter, dazu ein Request-Listener, der die request_id in den Context injiziert, bringt Sie in unter einer Stunde dorthin.
2. Distributed Tracing. OpenTelemetry-Instrumentierung an den Applikationsgrenzen (HTTP in, HTTP out, Datenbank, Queue). Es geht nicht um hübsche Waterfalls, es geht darum, “warum war dieser spezifische Request langsam?” ohne Raten beantworten zu können.
3. Einen Error Tracker. Sentry, Bugsnag oder Äquivalent. Keine Log-Datei. Das Signal-Rausch-Verhältnis von Error-Logs ist zu niedrig, um in der Incident-Response nützlich zu sein.
4. Ein kleines Set an Business-Metriken. Keine Infrastruktur-Metriken. Metriken wie “aufgegebene Orders pro Minute”, “gestartete Checkouts pro Minute”, “Zahlungsfehler pro Minute”. Das sind die Metriken, die Ihnen sagen, ob der Kunde ein Problem hat, was die einzige Definition von “das System ist kaputt” ist, die zählt.

Der Error Tracker und die Business-Metriken sind die beiden, die am häufigsten übersprungen werden, und sie sind die beiden, die am schnellsten zurückzahlen. Bringen Sie sie in Woche eins rein.

#8. Nehmen Sie Sicherheit ernst genug, um die Policy aufzuschreiben

Scaling legt eine Security-Oberfläche frei, die die Klein-Anwendungs-Phase verborgen hat. Mehr Benutzer, mehr Daten, mehr Angriffswert. Drei Dinge, die existieren müssen, bevor Sie einen Incident haben, nicht danach:

Eine Kadenz für Dependency-Upgrades. composer outdated --direct --strict läuft wöchentlich in CI, mit einer Person, die die Upgrades verantwortet. Ein Sprung auf die nächste Symfony-LTS-Linie ist ein Projekt, kein Nebenschauplatz. PHP-Versions-Updates stehen im Kalender. Das ist unter Skalierung wichtig, weil Schwachstellen gefunden und offengelegt werden, und die Lücke zwischen Offenlegung und Exploitation ist auf Tage geschrumpft. Ein Team, das quartalsweise upgraded, ist einen Monat lang exponiert. Ein Team, das monatlich upgraded, ist eine Woche lang exponiert.

Eine Secrets-Policy. Secrets leben in einem Secret Manager (AWS Secrets Manager, HashiCorp Vault, Doppler), nicht in .env-Dateien, die irgendwo committet sind. Symfonys secrets:set reicht für kleine Teams. Die Regel: Kein Secret ist jemals in einer git-Historie, wenn eines durchrutscht, rotieren Sie es innerhalb von 24 Stunden.

Rate Limiting auf den Auth-Endpoints. Symfonys RateLimiter-Komponente (und der eingebaute login_throttling-Firewall-Listener speziell für den Login), angewendet auf /login, /register und /password-reset, mit einer Token-Bucket-Policy. Das ist eine Stunde Arbeit, die die größte Klasse an Credential-Stuffing-Incidents verhindert, die Anwendungen treffen, wenn sie eine Größe erreichen, die sie lohnenswert zum Angreifen macht.

#9. Wissen Sie, was Sie jeder Request kostet

Das ist der Punkt, zu dem die meisten Teams nie kommen, und es ist der, der entscheidet, ob Ihre Scaling-Story nachhaltig ist oder ob Sie eines Morgens mit einer 40.000-Dollar-Cloud-Rechnung aufwachen.

Das Minimum: Sie sollten in unter fünf Minuten die Frage beantworten können “was kostet es uns, tausend Requests auf unseren teuersten Endpoint zu bedienen?”

Die Schritte, die Sie dorthin bringen:

• Taggen Sie jede Cloud-Ressource mit einem service- und environment-Tag. Erzwingen Sie das in Terraform oder welchem Provisioning-Tool Sie auch immer nutzen.
• Richten Sie einen wöchentlichen Kostenreport ein, aufgeschlüsselt nach Service. AWS Cost Explorer, GCP Billing Reports oder einfach ein CSV-Export in ein Spreadsheet für eine kleine Umgebung.
• Bauen Sie für die drei teuersten Services eine Per-Request-Kostenschätzung. RDS-Stunden pro zehntausend Queries, S3-Storage- und Request-Kosten pro zehntausend Uploads, Drittanbieter-API-Kosten pro Aufruf. Die müssen nicht exakt sein. Sie müssen als Zahl existieren.

Warum das wichtig ist: Scaling ist auch eine Preisentscheidung. Kostet Ihr teuerster Endpoint 4 Cent pro Aufruf und Ihr Kunde zahlt 9,99 Dollar/Monat für unbegrenzte Aufrufe, holen Ihre Unit Economics Sie irgendwann ein. Die Zahl zu kennen bedeutet, dass Sie dafür einpreisen, dafür optimieren oder dafür rate-limiten können, bevor die Rechnung kommt.

#Was zuerst repariert wird

Haben Sie eine typische PHP-Anwendung, die ein paar tausend Requests pro Tag erreicht hat und die Belastung spürt, ist die Reihenfolge ungefähr:

• Woche 1: Datenbank-Analyse, Slow-Query-Review, Top-Zwanzig-Audit. Indizes für die offensichtlichen Gewinne hinzufügen.
• Woche 2: Endpoint-Instrumentierung. p50/p95/p99 sichtbar machen. Die drei langsamsten Endpoints herauspicken und graben.
• Woche 3: Sessions zu Redis, falls noch nicht erledigt. Die schlimmsten synchronen externen API-Aufrufe in asynchrone Messages verlagern.
• Woche 4: Observability-Stack. Sentry + strukturierte Logs + ein grundlegendes Business-Metriken-Dashboard.
• Monat 2: Echte Deployment-Pipeline, falls noch nicht erledigt. HTTP-Cache auf den cachebaren Routen.
• Monat 3: Aufteilung auf zwei Messenger-Queues. Kosten-Tagging und wöchentlicher Kostenreport.

Sie werden feststellen, dass “zu Microservices umbauen” nicht auf dieser Liste steht. Das ist Absicht. Microservices lösen organisatorische Probleme, keine Scaling-Probleme, und ein Team, das die Punkte 1 bis 4 nicht erledigt hat, bekommt keine Scaling-Erleichterung, indem es Netzwerkaufrufe zwischen Modulen einzieht. Erledigen Sie erst die fundamentale Arbeit. Wenn Sie dann immer noch aufteilen müssen, tun Sie es aus einer Position operativer Kompetenz.

#Wann diese Checkliste nicht zutrifft

Diese Liste ist für Anwendungen, die aus ihrer ersten Architektur herausgewachsen sind, aber noch klein genug, dass ein Team das Gesamtbild halten kann. Konkret:

• Unter 1.000 Requests pro Tag: Sie haben noch kein Scaling-Problem, Sie haben ein zukünftiges Scaling-Problem. Machen Sie Punkt 1 (Datenbank langweilig), überspringen Sie den Rest, bis Wachstum sichtbar ist.
• Multi-Tenant-SaaS auf Enterprise-Skala: Die Tenant-Isolations-Arbeit dominiert alles andere, und die Queue-Aufteilung muss tenant-bewusst sein. Anderer Essay, andere Checkliste.
• Schwere Echtzeitanforderungen (WebSockets, Streaming): PHP ist nicht die falsche Wahl, aber das Betriebsprofil ist anders. Mercure oder Ähnliches bringt andere Anliegen mit sich als das Request-Response-Modell, das diese Liste voraussetzt.

Für alles dazwischen ist das die Liste.

Spürt Ihre PHP-Anwendung langsam die Belastung und Sie wollen Hilfe, diese Checkliste mit einem Team durchzuarbeiten, das es schon getan hat, dann ist mein Scaling-Engagement genau um diese Sequenz herum aufgebaut. Ein vierwöchiger Diagnose- und Remediation-Sprint, dann eine anhaltende Partnerschaft durch die Punkte, die länger als ein Quartal brauchen, um zu landen.

#Referenzen

• pg_stat_statements (PostgreSQL docs): die Extension zum Tracken von Planning- und Execution-Statistiken für jedes SQL-Statement, das Rückgrat des Top-Zwanzig-Reviews.
• Symfony HTTP Cache: Referenz für Symfonys Reverse-Proxy-Cache, ESI und die Cache-Control-Semantik, die auf cachebaren Routen verwendet wird.
• Symfony Messenger: der Message Bus für asynchrone Arbeit, inklusive Transport-Konfiguration und Routing.
• Symfony Sessions: Handler-Optionen inklusive RedisSessionHandler (kein Locking) und PdoSessionHandler (konfigurierbarer LOCK_TRANSACTIONAL).
• Symfony RateLimiter: Policies (Fixed Window, Sliding Window, Token Bucket) und wie sie sich auf bestimmte Endpoints anwenden lassen.
• Symfony Security: login throttling: das eingebaute Throttling auf Firewall-Ebene, speziell für /login entworfen.
• OpenTelemetry for PHP: das stabile Tracing-/Metrics-/Logs-SDK für Distributed Tracing über HTTP-, Datenbank- und Queue-Grenzen hinweg.