Een PHP-applicatie voorbereiden op verkeerspieken betekent niet dat je het gebruikelijke aantal bezoeken met een willekeurige factor vermenigvuldigt. De benodigde capaciteit hangt af van het aantal gelijktijdige verzoeken, hoelang elk verzoek duurt en welk werk het uitvoert: een gecachete pagina en een bewerking die meerdere externe services bevraagt, verbruiken niet dezelfde resources.
Het operationele doel is te weten welk onderdeel de service beperkt onder representatieve belasting, hoeveel marge er is en wat je moet doen wanneer die marge opraakt. Tests leveren bewijs voor besluitvorming; ze garanderen geen universele capaciteit, want het resultaat hangt af van de code, infrastructuur, gegevens en het werkelijke gebruikspatroon.
Schat de belasting in op basis van gelijktijdigheid en bewerkingstype
Dagelijkse of maandelijkse volumes zijn onvoldoende om de capaciteit te dimensioneren. Een applicatie kan veel bezoeken verspreid over uren ontvangen en ruim binnen de capaciteit blijven, of verzoeken in enkele minuten concentreren en overbelast raken. Om de belasting in te schatten, kijk je naar de aankomstsnelheid, de duur van verzoeken en het aandeel gelijktijdige bewerkingen.
Als richtlijn geldt: wanneer de duur toeneemt terwijl de aankomstsnelheid gelijk blijft, zijn er tegelijkertijd meer verzoeken actief. Daarom kan een trage afhankelijkheid de gelijktijdigheid verhogen, zelfs als het inkomende verkeer niet verandert. Verkeer kan ook ongelijk verdeeld zijn: een campagne kan het aantal productpagina’s en zoekopdrachten sterk verhogen, terwijl een periodeafsluiting juist authenticaties, exports of schrijfbewerkingen concentreert.
Begin met het identificeren van de routes en bewerkingen die van invloed zijn op de bedrijfsdoelen. Neem bijvoorbeeld openbare navigatie, zoeken, aanmelden, bestellingen aanmaken en relevante beheertaken op. Maak onderscheid tussen lees- en schrijfbewerkingen, cachebare en niet-cachebare verzoeken en synchrone verzoeken en taken die in een wachtrij kunnen worden verwerkt. Gebruik het algemene gemiddelde niet om een trage of kritieke route te verbergen.
Bouw een representatieve en veilige test
Definieer een of meer scenario’s op basis van beschikbare telemetrie, toegangslogboeken en de kalender met bekende gebeurtenissen. Documenteer welk aandeel van de verzoeken bij elke bewerking hoort, hoe de aankomstsnelheid varieert en hoelang elke fase duurt. Het is verstandig zowel aanhoudende belasting als een snelle toename te testen, omdat die verschillend gedrag blootleggen: geleidelijke uitputting van resources tegenover een abrupte reactie op een piek.
Voer de test uit in een omgeving die de productieconfiguratie voldoende weerspiegelt om de resultaten bruikbaar te maken. Controleer verschillen in het aantal processen, verbindingslimieten, caches, gegevensomvang en afhankelijkheden. Als een test op een geïsoleerde machine met kleine tabellen wordt uitgevoerd, toont dat niet aan hoe productie zal reageren. Genereer geen belasting tegen echte gebruikers zonder een expliciet plan en toestemming.
Bescherm gegevens al bij het ontwerpen van het scenario. Gebruik synthetische of geanonimiseerde gegevens, specifieke inloggegevens en minimale machtigingen; kopieer geen persoonsgegevens naar belastingstesttools zonder passende grondslag en beheersmaatregelen. Voorkom dat tests e-mails versturen, betalingen innen of onomkeerbare effecten veroorzaken. Gebruik voor externe bewerkingen testomgevingen of gecontroleerde vervangers, en houd er rekening mee dat een vervanger niet noodzakelijk de latentie of limieten van de echte service nabootst.
Meet latentie, fouten en verzadiging tegelijkertijd
Registreer de latentie per route en bekijk percentielen zoals p50, p95 en p99. Het gemiddelde kan stabiel blijven terwijl een deel van de verzoeken veel trager wordt; percentielen geven die staart beter weer. Meet ook het foutenpercentage, time-outs en het aantal voltooide verzoeken per tijdseenheid. Een test die veel verzoeken genereert, maar ook veel fouten oplevert, bewijst geen bruikbare capaciteit.
Breng deze metingen in verband met resources en wachtrijen. Houd in PHP de bezetting en wachtrij van de processen die verzoeken afhandelen in de gaten, evenals CPU, geheugen en herstarts. Gebruik je PHP-FPM, controleer dan de configuratie en meetgegevens van de processen en de webserver; de beschikbare indicator hangt af van de instrumentatie. Meet in de database actieve verbindingen, wachttijd voor het verkrijgen van een verbinding, trage queries, locks en CPU- of schijfgebruik. Houd ook caches, wachtrijen en externe afhankelijkheden in de gaten.
Stel drempelwaarden vast die gekoppeld zijn aan de gebruikerservaring en de bewerkingen, niet alleen aan CPU-gebruik. Voor een aankooproute kunnen bijvoorbeeld afgesproken maxima gelden voor latentie en foutenpercentage, terwijl een niet-kritieke export wachttijd of asynchrone verwerking toelaat. Controleer of klokken en observatievensters vergelijkbaar zijn en of je een toename in latentie kunt koppelen aan het onderdeel dat verzadigd raakte.
Lokaliseer eerst het knelpunt voordat je opschaalt
Zoek naar het eerste signaal dat verslechtert wanneer je de belasting geleidelijk verhoogt. Als de wachtrij van webprocessen groeit en de PHP-CPU-belasting hoog blijft, kan er per verzoek kostbaar werk plaatsvinden of zijn er onvoldoende processen beschikbaar. Als processen op verbindingen wachten terwijl de database nog capaciteit heeft, controleer dan de poollimiet of verbindingsconfiguratie. Als de database trage queries, locks of verzadiging vertoont, kan het toevoegen van PHP-processen de druk verhogen en het probleem verergeren.
Ook externe afhankelijkheden kunnen processen bezet houden. Controleer verbindings- en responstijden, snelheidslimieten en gedrag bij fouten. Een te lange time-out houdt resources bezet; onbeperkt opnieuw proberen kan de belasting vermenigvuldigen. Stel begrensde time-outs en een selectief retrybeleid in, met oplopende wachttijden waar dat gepast is, en herhaal niet automatisch niet-idempotente bewerkingen zonder bescherming.
Maak onderscheid tussen onvoldoende capaciteit en inefficiëntie. Een query die te veel rijen doorloopt, herhaalde aanroepen naar dezelfde service of overbodige berekeningen blijven kostbaar, ook wanneer je servers toevoegt. Profileer representatieve routes en verminder het werk per verzoek: optimaliseer queries en indexen op basis van bewijs, beperk resultaten, verwijder onnodige aanroepen en benut caching wanneer consistentie en privacy dat toelaten. Herhaal daarna de test om te controleren of de verbetering onder belasting standhoudt.
Grijp in de juiste volgorde in en plan gecontroleerde degradatie
Verlaag eerst de kosten van het werk per verzoek en los problemen op met queries of afhankelijkheden die de beperkende factor vormen. Controleer daarna de gelijktijdigheidslimieten, webprocessen en verbindingspools. Meer processen kunnen de paralleliteit verbeteren totdat CPU, geheugen of database verzadigd raakt; meer verbindingen configureren dan de database aankan, verplaatst de wachtrij alleen maar. Wijzig één variabele tegelijk en meet opnieuw.
Verticale scaling — meer resources op één instance — kan een eenvoudige ingreep zijn als het onderdeel kan meegroeien en er geen structurele limiet is. Horizontale scaling — meer instances — vereist dat de uitrol, sessies, bestanden, taken en database die verdeling ondersteunen. Controleer load balancing, gedeelde of externe opslag waar nodig, de gezondheid van instances en gedeelde limieten, zoals databaseverbindingen. Geen van beide opties lost op zichzelf een inefficiënte query op.
Bepaal wat behouden moet blijven wanneer de capaciteit schaars is. Geef, afhankelijk van het product, prioriteit aan authenticatie, essentiële bewerkingen of transactiebevestigingen; stel rapporten uit, beperk kostbare zoekopdrachten of schakel niet-essentiële functies tijdelijk uit. Gebruik wachtrijen voor werk dat later kan worden afgerond en informeer de gebruiker over de status. Pas snelheidslimieten of expliciete reacties op overbelasting toe, met een zorgvuldig retrybeleid. Gecontroleerde degradatie moet voorkomen dat bevestigde bewerkingen verloren gaan en een begrijpelijk alternatief bieden; ze mag geen fictief succes teruggeven.
Houd een logboek bij om tests om te zetten in een operationele beslissing: noteer het scenario, de configuratie, resultaten per route, de eerste waargenomen limiet, uitgevoerde wijzigingen en acceptatiecriteria. Herhaal de test nadat relevante code, infrastructuur, gegevens of afhankelijkheden zijn gewijzigd. Controleer vóór een verwachte piek de meldingen, beschikbare capaciteit, rollbackprocedures en verantwoordelijken voor besluitvorming.
Checklist voor een piek
- Scenario: weerspiegelt plausibele routes, verhoudingen, tempo en duur; omvat een snelle toename en aanhoudende belasting.
- Beveiliging: gebruikt geschikte gegevens en inloggegevens, voorkomt ongewenste echte effecten en beheerst de bestemming van de test.
- Observeerbaarheid: brengt p95/p99-latentie en fouten in verband met throughput, PHP-processen, database, cache en afhankelijkheden.
- Diagnose: identificeert de eerste limiet en bevestigt of die wordt veroorzaakt door verzadiging, queries, gelijktijdigheid of externe wachttijden.
- Wijziging: verandert één oorzaak tegelijk, vergelijkt resultaten en controleert of de verzadiging niet naar een andere laag verschuift.
- Veerkracht: definieert limieten, prioriteiten, degradatie, communicatie en herstel zonder bevestigde bewerkingen te verliezen.
- Herhaling: legt acceptatiecriteria vast en test opnieuw na belangrijke wijzigingen en vóór voorzienbare gebeurtenissen.
Rigoureus dimensioneren betekent weten hoe de applicatie op concrete scenario’s reageert en beslissingen nemen met voldoende marge, niet jagen op een abstract aantal gebruikers. Metingen maken zichtbaar waar investeringen nodig zijn: optimalisatie, aanpassing van gelijktijdigheid, extra capaciteit of een degradatiebeleid dat essentiële functies bruikbaar houdt.
