Latens i Blobblagring
Svarstid, som ibland refereras till som svarstid, är den tid som ett program måste vänta på att en begäran ska slutföras. 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 svarstid 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 ger betydligt lägre och mer konsekvent svarstid än standardblockblobar via högpresterande SSD-diskar. Mer information finns i Premium-prestandablockbloblagring i frekventa, lågfrekventa och arkivbaserade åtkomstnivåer för blobdata.
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 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, om trådantalet fördubblas till två, bör programmet kunna uppnå 40 IOPS. Om de utestå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 de lagringsmedier som används, brus från andra arbetsbelastningar, underhållsuppgifter och andra faktorer. Slutligen kan nätverksanslutningen mellan klienten och servern påverka Svarstiden för Azure Storage på grund av överbelastning, omdirigering eller andra avbrott.
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 vi 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 svarstid för E2E-svarstid och genomsnittlig svarstid för lyckad server för en exempelarbetsbelastning som anropar Get Blob åtgärden:
Under normala förhållanden är det liten skillnad 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 server och upptäcker 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, bör 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 över 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 ägnas mer tid åt 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 för 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 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 serverfördröjning, vilket ökar gapet mellan de två måtten.
Lika viktigt är nätverksgränssnittet och nätverkspipan 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, INTERNET-routning och Internet-tillstånd kan påverka den totala 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 server i kontexten för din programmiljö, beroende på din arbetsbelastningsprofil, programkonfigurationsinställningar, 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.