Checklista för prestanda och skalbarhet för kölagring
Microsoft har utvecklat många beprövade metoder för att utveckla högpresterande program med Queue Storage. Den här checklistan identifierar viktiga metoder som utvecklare kan följa för att optimera prestanda. Tänk på dessa metoder när du utformar ditt program och under hela processen.
Azure Storage har skalbarhets- och prestandamål för kapacitet, transaktionshastighet och bandbredd. Mer information om skalbarhetsmål för Azure Storage finns i Skalbarhets- och prestandamål för standardlagringskonton och skalbarhets- och prestandamål för Queue Storage.
Checklista
Den här artikeln organiserar beprövade metoder för prestanda i en checklista som du kan följa när du utvecklar ditt Queue Storage-program.
Skalbarhetsmål
Om ditt program närmar sig eller överskrider något av skalbarhetsmålen kan det uppstå ökade transaktionsfördröjningar eller begränsningar. När Azure Storage begränsar ditt program börjar tjänsten returnera 503 (Server Busy) eller 500 (Operation Timeout) felkoder. Att undvika dessa fel genom att hålla sig inom gränserna för skalbarhetsmålen är en viktig del av att förbättra programmets prestanda.
Mer information om skalbarhetsmål för Queue Storage finns i Skalbarhets- och prestandamål för Azure Storage.
Maximalt antal lagringskonton
Om du närmar dig det maximala antalet lagringskonton som tillåts för en viss kombination av prenumerationer/regioner använder du flera lagringskonton för att fragmentera för att öka ingress-, utgående, I/O-åtgärder per sekund (IOPS) eller kapacitet? I det här scenariot rekommenderar Microsoft att du drar nytta av ökade gränser för lagringskonton för att minska antalet lagringskonton som krävs för din arbetsbelastning om möjligt. Kontakta Azure Support för att begära ökade gränser för ditt lagringskonto.
Kapacitets- och transaktionsmål
Om ditt program närmar sig skalbarhetsmålen för ett enda lagringskonto bör du överväga att använda någon av följande metoder:
- Om skalbarhetsmålen för köer inte är tillräckliga för ditt program använder du flera köer och distribuerar meddelanden mellan dem.
- Ompröva arbetsbelastningen som gör att ditt program närmar sig eller överskrider skalbarhetsmålet. Kan du utforma den annorlunda för att använda mindre bandbredd eller kapacitet, eller färre transaktioner?
- Om ditt program måste överskrida något av skalbarhetsmålen skapar du flera lagringskonton och partitionera dina programdata mellan dessa flera lagringskonton. Om du använder det här mönstret måste du utforma programmet så att du kan lägga till fler lagringskonton i framtiden för belastningsutjämning. Själva lagringskontona har ingen annan kostnad än din användning när det gäller lagrade data, transaktioner som görs eller data som överförs.
- Om ditt program närmar sig bandbreddsmålen bör du överväga att komprimera data på klientsidan för att minska den bandbredd som krävs för att skicka data till Azure Storage. Även om komprimering av data kan spara bandbredd och förbättra nätverksprestanda, kan det också ha negativa effekter på prestanda. Utvärdera prestandapåverkan för de ytterligare bearbetningskraven för datakomprimering och dekomprimering på klientsidan. Tänk på att lagring av komprimerade data kan göra det svårare att felsöka eftersom det kan vara svårare att visa data med hjälp av standardverktyg.
- Om ditt program närmar sig skalbarhetsmålen kontrollerar du att du använder en exponentiell backoff för återförsök. Det är bäst att försöka undvika att nå skalbarhetsmålen genom att implementera rekommendationerna som beskrivs i den här artikeln. Om du använder en exponentiell backoff för återförsök hindrar det dock programmet från att försöka igen snabbt, vilket kan göra begränsningen värre. Mer information finns i avsnittet Timeout- och Server Busy-fel .
Nätverk
Programmets fysiska nätverksbegränsningar kan ha en betydande inverkan på prestandan. I följande avsnitt beskrivs några av de begränsningar som användare kan stöta på.
Klientnätverksfunktion
Bandbredd och kvaliteten på nätverkslänken spelar viktiga roller i programmets prestanda, enligt beskrivningen i följande avsnitt.
Dataflöde
För bandbredd är problemet ofta klientens funktioner. Större Azure-instanser har nätverkskort med större kapacitet, så du bör överväga att använda en större instans eller fler virtuella datorer om du behöver högre nätverksgränser från en enda dator. Om du kommer åt Azure Storage från ett lokalt program gäller samma regel: förstå nätverksfunktionerna på klientenheten och nätverksanslutningen till Azure Storage-platsen och förbättra dem efter behov eller utforma programmet så att det fungerar inom deras funktioner.
Länkkvalitet
Som med all nätverksanvändning bör du tänka på att nätverksförhållanden som resulterar i fel och paketförlust saktar ned effektivt dataflöde. Att använda Wireshark eller Network Monitor kan hjälpa dig att diagnostisera det här problemet.
Plats
I alla distribuerade miljöer ger det bästa prestanda att placera klienten nära servern. För åtkomst till Azure Storage med lägst svarstid är den bästa platsen för klienten inom samma Azure-region. Om du till exempel har en Azure-webbapp som använder Azure Storage letar du upp dem båda i en enda region, till exempel USA, västra eller Asien, sydöstra. Genom att samlokalisera resurser minskar svarstiden och kostnaden, eftersom bandbreddsanvändningen i en enda region är kostnadsfri.
Om klientprogram får åtkomst till Azure Storage men inte finns i Azure, till exempel mobilappar eller lokala företagstjänster, kan det minska svarstiden att hitta lagringskontot i en region nära dessa klienter. Om dina klienter är brett fördelade (till exempel vissa i Nordamerika och vissa i Europa) kan du överväga att använda ett lagringskonto per region. Den här metoden är enklare att implementera om de data som programmet lagrar är specifika för enskilda användare och inte kräver replikering av data mellan lagringskonton.
SAS och CORS
Anta att du behöver auktorisera kod som JavaScript som körs i en användares webbläsare eller i en mobilapp för att få åtkomst till data i Azure Storage. En metod är att skapa ett tjänstprogram som fungerar som proxy. Användarens enhet autentiserar med tjänsten, vilket i sin tur ger åtkomst till Azure Storage-resurser. På så sätt kan du undvika att exponera dina lagringskontonycklar på osäkra enheter. Den här metoden medför dock betydande kostnader för tjänstprogrammet, eftersom alla data som överförs mellan användarens enhet och Azure Storage måste passera genom tjänstprogrammet.
Du kan undvika att använda ett tjänstprogram som proxy för Azure Storage med hjälp av signaturer för delad åtkomst (SAS). Med HJÄLP av SAS kan du aktivera användarens enhet för att göra begäranden direkt till Azure Storage med hjälp av en begränsad åtkomsttoken. Om en användare till exempel vill ladda upp ett foto till ditt program kan tjänstprogrammet generera en SAS och skicka den till användarens enhet. SAS-token kan ge behörighet att skriva till en Azure Storage-resurs under ett angivet tidsintervall, varefter SAS-token upphör att gälla. Mer information om SAS finns i Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS).
Normalt tillåter inte en webbläsare JavaScript på en sida som finns på en webbplats i en domän för att utföra vissa åtgärder, till exempel skrivåtgärder, till en annan domän. Den här principen kallas för principen för samma ursprung och förhindrar att ett skadligt skript på en sida får åtkomst till data på en annan webbsida. Principen för samma ursprung kan dock vara en begränsning när du skapar en lösning i molnet. Resursdelning mellan ursprung (CORS) är en webbläsarfunktion som gör att måldomänen kan kommunicera med webbläsaren som den litar på begäranden som kommer från källdomänen.
Anta till exempel att ett webbprogram som körs i Azure gör en begäran om en resurs till ett Azure Storage-konto. Webbprogrammet är källdomänen och lagringskontot är måldomänen. Du kan konfigurera CORS för någon av Azure Storage-tjänsterna för att kommunicera med webbläsaren om att begäranden från källdomänen är betrodda av Azure Storage. Mer information om CORS finns i Stöd för resursdelning mellan ursprung (CORS) för Azure Storage.
Både SAS och CORS kan hjälpa dig att undvika onödig belastning på webbappen.
.NET-konfiguration
För projekt som använder .NET Framework innehåller det här avsnittet några snabbkonfigurationsinställningar som du kan använda för att göra betydande prestandaförbättringar. Om du använder ett annat språk än .NET kontrollerar du om liknande begrepp gäller på det valda språket.
Öka standardgränsen för anslutning
Kommentar
Det här avsnittet gäller för projekt som använder .NET Framework, eftersom anslutningspooler styrs av klassen ServicePointManager. .NET Core introducerade en betydande ändring av hantering av anslutningspooler, där anslutningspooler sker på HttpClient-nivå och poolstorleken inte är begränsad som standard. Det innebär att HTTP-anslutningar skalas automatiskt för att uppfylla din arbetsbelastning. Om det är möjligt rekommenderar vi att du använder den senaste versionen av .NET för att dra nytta av prestandaförbättringar.
För projekt som använder .NET Framework kan du använda följande kod för att öka standardanslutningsgränsen (som vanligtvis är 2 i en klientmiljö eller 10 i en servermiljö) till 100. Vanligtvis bör du ange värdet till ungefär det antal trådar som används av ditt program. Ange anslutningsgränsen innan du öppnar några anslutningar.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Mer information om gränser för anslutningspooler i .NET Framework finns i .NET Framework Anslut ionspoolgränser och det nya Azure SDK för .NET.
Andra programmeringsspråk finns i dokumentationen för att fastställa hur anslutningsgränsen ska anges.
Öka det minsta antalet trådar
Om du använder synkrona anrop tillsammans med asynkrona uppgifter kanske du vill öka antalet trådar i trådpoolen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Mer information finns i metoden ThreadPool.SetMinThreads .
Obundna parallelliteter
Parallellitet kan vara bra för prestanda, men var försiktig med att använda obundna parallelliteter, vilket innebär att det inte finns någon gräns för antalet trådar eller parallella begäranden. Se till att begränsa parallella begäranden om att ladda upp eller ladda ned data, att komma åt flera partitioner i samma lagringskonto eller att komma åt flera objekt i samma partition. Om parallelliteten är obundna kan programmet överskrida klientenhetens funktioner eller lagringskontots skalbarhetsmål, vilket resulterar i längre svarstider och begränsningar.
Klientbibliotek och -verktyg
Använd alltid de senaste klientbiblioteken och verktygen från Microsoft för bästa prestanda. Azure Storage-klientbibliotek är tillgängliga för olika språk. Azure Storage har även stöd för PowerShell och Azure CLI. Microsoft utvecklar aktivt dessa klientbibliotek och verktyg med prestanda i åtanke, håller dem uppdaterade med de senaste tjänstversionerna och ser till att de hanterar många av de beprövade prestandametoderna internt. Mer information finns i referensdokumentationen för Azure Storage.
Hantera tjänstfel
Azure Storage returnerar ett fel när tjänsten inte kan bearbeta en begäran. Att förstå de fel som kan returneras av Azure Storage i ett visst scenario är användbart för att optimera prestanda.
Timeout- och Server Busy-fel
Azure Storage kan begränsa ditt program om det närmar sig skalbarhetsgränserna. I vissa fall kanske Azure Storage inte kan hantera en begäran på grund av ett tillfälligt villkor. I båda fallen kan tjänsten returnera ett fel på 503 (Server Busy) eller 500 (Timeout). Dessa fel kan också inträffa om tjänsten balanserar om datapartitioner för att möjliggöra högre dataflöde. Klientprogrammet bör vanligtvis försöka utföra åtgärden igen som orsakar något av dessa fel. Men om Azure Storage begränsar ditt program eftersom det överskrider skalbarhetsmålen, eller om tjänsten inte kunde hantera begäran av någon annan anledning, kan aggressiva återförsök göra problemet värre. Vi rekommenderar att du använder en exponentiell princip för återförsök och att klientbiblioteken använder det här beteendet som standard. Ditt program kan till exempel försöka igen efter 2 sekunder, sedan 4 sekunder, sedan 10 sekunder, sedan 30 sekunder och sedan ge upp helt. På så sätt minskar programmet avsevärt belastningen på tjänsten i stället för att förvärra beteendet som kan leda till begränsning.
Anslut ivity errors can betrieds immediately, because they are't the result of throttling and are expected to be transient.
Fel som inte kan försökas igen
Klientbiblioteken hanterar återförsök med en medvetenhet om vilka fel som kan försökas igen och vilka som inte kan göra det. Men om du anropar Azure Storage REST API direkt finns det några fel som du inte bör försöka igen. Ett 400-fel (Bad Request) anger till exempel att klientprogrammet skickade en begäran som inte kunde bearbetas eftersom den inte fanns i det förväntade formuläret. Om du skickar den här begäran igen får du samma svar varje gång, så det är ingen idé att försöka igen. Om du anropar Azure Storage REST API direkt bör du vara medveten om potentiella fel och om de ska göras om.
Mer information om Azure Storage-felkoder finns i Status- och felkoder.
Inaktivera Nagles algoritm
Nagles algoritm implementeras i stor utsträckning i TCP/IP-nätverk som ett sätt att förbättra nätverksprestanda. Det är dock inte optimalt under alla omständigheter (till exempel mycket interaktiva miljöer). Nagles algoritm har en negativ inverkan på prestanda för begäranden till Azure Table Storage och du bör inaktivera den om möjligt.
Meddelandestorlek
Köprestanda och skalbarhet minskar när meddelandestorleken ökar. Placera endast den information som mottagaren behöver i ett meddelande.
Batchhämtning
Du kan hämta upp till 32 meddelanden från en kö i en enda åtgärd. Batchhämtning kan minska antalet rundturer från klientprogrammet, vilket är särskilt användbart för miljöer, till exempel mobila enheter, med hög svarstid.
Intervall för kösökning
De flesta program söker efter meddelanden från en kö, vilket kan vara en av de största transaktionskällorna för programmet. Välj avsökningsintervallet klokt: Avsökning för ofta kan leda till att programmet närmar sig skalbarhetsmålen för kön. Men vid 200 000 transaktioner för 0,01 USD (i skrivande stund) skulle en enskild processorsökning en gång i sekunden under en månad kosta mindre än 15 cent, så kostnaden är vanligtvis inte en faktor som påverkar ditt val av avsökningsintervall.
Uppdaterad kostnadsinformation finns i Priser för Azure Storage.
Utföra en uppdateringsmeddelandeåtgärd
Du kan utföra en uppdateringsmeddelandeåtgärd för att öka tidsgränsen för osynlighet eller uppdatera tillståndsinformationen för ett meddelande. Den här metoden kan vara effektivare än att ha ett arbetsflöde som skickar ett jobb från en kö till nästa, eftersom varje steg i jobbet har slutförts. Ditt program kan spara jobbtillståndet i meddelandet och sedan fortsätta att arbeta, i stället för att spara meddelandet för nästa steg i jobbet varje gång ett steg slutförs. Tänk på att varje uppdateringsmeddelandeåtgärd räknas mot skalbarhetsmålet.
Programmets arkitektur
Använd köer för att göra programarkitekturen skalbar. Följande visar några sätt att använda köer för att göra programmet mer skalbart:
- Du kan använda köer för att skapa kvarvarande uppgifter för bearbetning och jämna ut arbetsbelastningar i ditt program. Du kan till exempel köa begäranden från användare för att utföra processorintensivt arbete, till exempel ändra storlek på uppladdade bilder.
- Du kan använda köer för att frikoppla delar av programmet så att du kan skala dem separat. En webbklientdel kan till exempel placera undersökningsresultat från användare i en kö för senare analys och lagring. Du kan lägga till fler arbetsrollinstanser för att bearbeta ködata efter behov.