Latens i Blobblagring
Svarstid, som ibland refereras till som svarstid, är den tid som ett program måste vänta tills en begäran har slutförts. Svarstiden kan direkt påverka ett programs prestanda. Låg svarstid är ofta viktigt för scenarier med människor i loopen, till exempel att utföra kreditkortstransaktioner eller läsa in webbsidor. System som behöver bearbeta inkommande händelser med höga hastigheter, till exempel telemetriloggning eller IoT-händelser, kräver också låg svarstid. Den här artikeln beskriver hur du förstår och mäter svarstider för åtgärder på blockblobar och hur du utformar dina program för låg svarstid.
Azure Storage erbjuder två olika prestandaalternativ för blockblobar: premium och standard. Premium-blockblobar erbjuder betydligt lägre och mer konsekventa svarstider än standardblockblobar via högpresterande SSD-diskar. Mer information finns i Premium-blockbloblagringskonton.
Om Svarstid för Azure Storage
Svarstiden för Azure Storage är relaterad till begärandefrekvenser för Azure Storage-åtgärder. Begärandefrekvenser kallas även för indata-/utdataåtgärder per sekund (IOPS).
Beräkna begärandefrekvensen genom att först fastställa hur lång tid varje begäran tar att slutföra och sedan beräkna hur många begäranden som kan bearbetas per sekund. Anta till exempel att en begäran tar 50 millisekunder (ms) att slutföra. Ett program som använder en tråd med en utestående läs- eller skrivåtgärd bör uppnå 20 IOPS (1 sekund eller 1 000 ms/50 ms per begäran). Teoretiskt sett bör programmet kunna uppnå 40 IOPS om antalet trådar fördubblas till två. Om de enastående asynkrona läs- eller skrivåtgärderna för varje tråd fördubblas till två bör programmet kunna uppnå 80 IOPS.
I praktiken skalas inte begärandefrekvenserna alltid så linjärt, på grund av omkostnader i klienten från schemaläggning av uppgifter, kontextväxling och så vidare. På tjänstsidan kan svarstiden variera på grund av tryck på Azure Storage-systemet, skillnader i det lagringsmedium som används, brus från andra arbetsbelastningar, underhållsuppgifter och andra faktorer. Slutligen kan nätverksanslutningen mellan klienten och servern påverka Azure Storage-svarstiden på grund av överbelastning, omdirigering eller andra störningar.
Azure Storage-bandbredd, även kallat dataflöde, är relaterad till begärandefrekvensen och kan beräknas genom att multiplicera begärandefrekvensen (IOPS) med begärandestorleken. Om du till exempel antar 160 begäranden per sekund resulterar varje 256 KiB av data i dataflöde på 40 960 KiB per sekund eller 40 MiB per sekund.
Svarstidsmått för blockblobar
Azure Storage tillhandahåller två svarstidsmått för blockblobar. Dessa mått kan visas i Azure Portal:
Svarstiden från slutpunkt till slutpunkt (E2E) mäter intervallet från när Azure Storage tar emot det första paketet i begäran tills Azure Storage tar emot en klientbekräftelse för det sista paketet i svaret.
Serverns svarstid mäter intervallet från när Azure Storage tar emot det sista paketet i begäran tills det första paketet i svaret returneras från Azure Storage.
Följande bild visar genomsnittlig lyckad E2E-svarstid och Genomsnittlig svarstid för lyckad server för en exempelarbetsbelastning som anropar åtgärden Get Blob :
Under normala förhållanden finns det liten lucka mellan svarstid från slutpunkt till slutpunkt och serverfördröjning, vilket är vad bilden visar för exempelarbetsbelastningen.
Om du granskar måtten för svarstid från slutpunkt till slutpunkt och ser att svarstiden från slutpunkt till slutpunkt är betydligt högre än serverns svarstid, undersöker och adresserar du källan till den ytterligare svarstiden.
Om svarstiden från slutpunkt till slutpunkt och server är liknande, men du behöver kortare svarstid, kan du överväga att migrera till Premium Block Blob Storage.
Faktorer som påverkar svarstiden
Den viktigaste faktorn som påverkar svarstiden är åtgärdsstorleken. Det tar längre tid att slutföra större åtgärder på grund av mängden data som överförs via nätverket och bearbetas av Azure Storage.
Följande diagram visar den totala tiden för åtgärder av olika storlekar. För små mängder data används svarstidsintervallet främst för att hantera begäran i stället för att överföra data. Svarstidsintervallet ökar bara något när åtgärdsstorleken ökar (markerad 1 i diagrammet nedan). När åtgärdsstorleken ökar ytterligare läggs mer tid på att överföra data, så att det totala svarstidsintervallet delas mellan hantering av begäranden och dataöverföring (markerat 2 i diagrammet nedan). Med större åtgärdsstorlekar används svarstidsintervallet nästan uteslutande till att överföra data och begärandehanteringen är i stort sett obetydlig (markerad 3 i diagrammet nedan).
Klientkonfigurationsfaktorer som samtidighet och trådning påverkar också svarstiden. Det övergripande dataflödet beror på hur många lagringsbegäranden som körs vid en viss tidpunkt och på hur ditt program hanterar trådning. Klientresurser som CPU, minne, lokal lagring och nätverksgränssnitt kan också påverka svarstiden.
Bearbetning av Azure Storage-begäranden kräver processor- och minnesresurser för klienten. Om klienten är under press på grund av en underbemannad virtuell dator eller någon skenande process i systemet finns det färre resurser tillgängliga för att bearbeta Azure Storage-begäranden. All konkurrens eller brist på klientresurser resulterar i en ökning av svarstiden från slutpunkt till slutpunkt utan ökad serversvarstid, vilket ökar klyftan mellan de två måtten.
Lika viktigt är nätverksgränssnittet och nätverksröret mellan klienten och Azure Storage. Enbart fysiskt avstånd kan vara en viktig faktor, till exempel om en virtuell klientdator finns i en annan Azure-region eller lokalt. Andra faktorer som nätverkshopp, ISP-routning och Internettillstånd kan påverka den övergripande lagringsfördröjningen.
Om du vill utvärdera svarstiden måste du först upprätta baslinjemått för ditt scenario. Baslinjemått ger dig förväntad svarstid från slutpunkt till slutpunkt och serverfördröjning i kontexten för din programmiljö, beroende på din arbetsbelastningsprofil, inställningar för programkonfiguration, klientresurser, nätverkspipa och andra faktorer. När du har baslinjemått kan du lättare identifiera onormala kontra normala förhållanden. Med baslinjemått kan du också se effekterna av ändrade parametrar, till exempel programkonfiguration eller VM-storlekar.