Volg één langzaam verzoek voordat u de grootte aanpast

Kies een verzoek met een duidelijk verwacht resultaat

Registreer voor een illustratief rapport-endpoint het routepatroon, de geschatte gegevensgrootte, de authenticatiecontext en of het achtergrondwerk creëert. Gebruik een testaccount en representatieve gesanitiseerde gegevens. Kopieer geen tokens, klantidentificatoren of volledige request bodies naar een incidentnotitie.

Scheid de opstartkosten van het eerste verzoek van herhaald steady-state gedrag. Registreer het UTC-venster en de release-revisie. Bepaal of alle routes traag zijn, alleen grote rapporten zijn getroffen, of de vertraging één externe afhankelijkheid volgt. Deze onderscheidingen maken de volgende meting nuttiger dan een brede verzameling niet-gerelateerde metrics.

Bouw een tijdlijn zonder dubbel te tellen

OpenTelemetry-traces verbinden gerelateerde spans via doorgegeven context over servicegrenzen heen. Alleen overeenkomende tijdstempels zijn niet voldoende. Geneste synchrone spans en parallelle aanroepen kunnen overlappen. Asynchrone kinderen kunnen hun parent overleven, dus het optellen van elke span-duur kan verstreken tijd dubbel tellen. Volg de bewerkingen die bepalen wanneer het verzoek voltooid is.

Technische referentie: OpenTelemetry-traces · Einde-gedrag van OpenTelemetry-span.

Het grootste interval geeft aan waar moet worden geïnspecteerd, niet de grondoorzaak. Een database-interval gemeten in de API kan wachten op een verbinding omvatten voordat een query de database bereikt. Ontbrekende telemetrie bewijst ook niet dat er geen werk heeft plaatsgevonden; inspecteer sampling en instrumentatiedekking.

Correleer applicatie- en hostobservaties

Verzamel request-timings, fouten, databaseverbindingsgebruik, wachtrijleeftijd, CPU, geheugen en schijf druk voor hetzelfde venster. Noteer gelijktijdige back-ups, migraties of releases. Eén screenshot van het gebruik kan de piek missen die het verzoek beïnvloedde.

Gebruik correlatie-ID's en tijdstempels in geredigeerde logs met passende retentie en toegangscontroles. Vermijd ruwe secrets, klantpayloads en onbegrensde metric-labels. Instrumenteer de grens die nodig is voor de hypothese en beoordeel de overhead. Een nieuwe tracing-agent is zelf een wijziging die het observeren waard is.

Inspecteer de query zonder een nieuw incident te veroorzaken

Identificeer eerst de queryvorm, kenmerken van de invoergrootte en verbindings- of lock-wachttijden. PostgreSQL EXPLAIN beschrijft een plan; EXPLAIN ANALYZE voert de statement daadwerkelijk uit en voegt instrumentatie-overhead toe. Een write kan gegevens wijzigen, terwijl een dure read nog steeds belasting creëert. Gebruik een geïsoleerde representatieve database voor het eerste onderzoek.

Planner-kosten zijn geen verstreken milliseconden. Een kleine testtabel kan een ander plan opleveren dan de grotere dataset van de applicatie. Beoordeel statistieken, indexen en distributie, en vergelijk dezelfde queryvorm na de wijziging. Plak nooit een onbekende write in een analysecommando op productie alleen om timing te verkrijgen.

Technische referentie: PostgreSQL EXPLAIN.

Voorspel wat één wijziging zou moeten verbeteren

Als pool-wachten domineert, inspecteer dan worker-verbindingen of verzoeken die onnodig een verbinding vasthouden. Als query-uitvoering domineert, inspecteer dan het plan en de opgevraagde rijen. Als een externe API domineert, beoordeel dan time-outs, herhalingen en of het werk synchroon moet zijn. CPU-verzadiging tijdens serialisatie wijst op een ander experiment.

Schrijf een voorspelling: het verlagen van exportconcurrency zou het wachten op de API-pool moeten verminderen, terwijl exports langer duren. Dit legt de afweging bloot. Herhaal dezelfde requestmix, vergelijk latentie en fouten, en controleer dat de verbetering niet simpelweg falen heeft verplaatst naar een steeds groter wordende wachtrij.

Bewaar het resultaat en de onzekerheid ervan

Registreer de oorspronkelijke observatie, geteste wijziging, vergelijkingsmethode en resterende onzekerheid. Als bewijs de hypothese tegenspreekt, draai de geïsoleerde wijziging waar passend terug en onderzoek een andere grens. Vermijd het opstapelen van permanente tuningwijzigingen zonder uitleg.

Schaal op wanneer metingen een resourcebeperking identificeren die extra toewijzing kan verhelpen. Gebruik het workloadbudget en leg een release-regressie vast in de incidentbrief. De uitkomst is een beargumenteerde diagnose, geen belofte over latentie of een provider-benchmark.