Tolka tiderna för webbläsare, API och databas rätt
Ett tänkt listanrop kopplar mätgränser till en förfrågningsidentifierare, så att tider som ingår i varandra inte räknas flera gånger.
En långsam skärm visar inte var tiden går förlorad. En riktad undersökning kräver att utveckling och drift använder samma uppgift, samma förfrågan och tydligt angivna mätgränser.
Följande exempel är helt hypotetiskt. Identifieraren req-17, alla tider och frågestrukturen är påhittade. Inget kundsystem har mätts.
Avgränsa en konkret förfrågan
Här laddar en portal en beställningslista med 20 rader. Dessa antagna mätvärden hör till förfrågan:
Mätpunkt | Antagen tid | Vad som mäts |
|---|---|---|
Webbläsare | 2400 ms | Laddning av API-resursen tills hela svaret har tagits emot |
API | 2300 ms | Behandling av förfrågan i servern |
Databasåtkomst | 2100 ms | Summan av databasanrop som här körs i följd inom behandlingen |
Databastiden ingår i servertiden, som i sin tur ingår i hämtningen. Att lägga ihop dem räknar samma tid flera gånger. Vid parallella anrop kan summan också överstiga den förflutna tiden.
Webbläsarens och serverns absoluta starttidpunkter kan inte enkelt dras från varandra utan en lämplig tidsgrund. Använd definierade varaktigheter och en spårbar koppling till samma förfrågan.
Undersök den del som sticker ut
Det påhittade flödet ger 21 databasanrop: en listfråga och sedan en detaljfråga per rad. Den upprepade åtkomsten blir därmed en konkret punkt att undersöka. Ett högt antal skulle inte ensamt bevisa strukturen; här ingår den uttryckligen i exemplet.
Undersök vilken information vyn faktiskt behöver. En avgränsad gemensam hämtning kan vara en möjlig ändring. Den måste ge samma tillåtna poster. Det följer inte att alla data bör hämtas i en enorm fråga.
Webbläsarvärdet slutar när resursen tagits emot. Det bevisar inte att vyn då är användbar. Om den är fortsatt blockerad måste bearbetning, rendering och andra resurser undersökas separat.
Pröva under jämförbara förhållanden
Anteckna programversion, uppgift, datamängd, filter och behörighetsområde. Samtidig belastning och cachens tillstånd hör också till. En tom och en fylld cache kan ge olika resultat.
Upprepa flödet före och efter ändringen under lämpliga förhållanden. Kontrollera resultat och åtkomstgränser tillsammans med tiden. Ett ovanligt snabbt anrop bevisar ingen allmän förbättring.
Åtkomst till tekniska mätvärden bör styras; kundinnehåll behövs inte för denna anteckning. Undersökningen ska ge en motiverad nästa ändring med tydlig omfattning, inte ett allmänt omdöme om hela applikationens hastighet.
Källor
Läs vidare
Alla artiklar
Mjukvaruutveckling med ASES
Skräddarsydd programvara, webb- och mobilappar