Checklista för prestanda och skalbarhet för Blob Storage

Microsoft har utvecklat ett antal beprövade metoder för att utveckla högpresterande program med Blob 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 samt skalbarhets- och prestandamål för Blob 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 Blob 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 felkoderna 503 (servern är upptagen) eller 500 (timeout för åtgärd). 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 kötjänsten 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 utvärderar du ditt scenario och avgör om något av följande villkor gäller:

• Använder du lagringskonton för att lagra ohanterade diskar och lägga till dessa diskar på dina virtuella datorer? I det här scenariot rekommenderar Microsoft att du använder hanterade diskar. Hanterade diskar skalas automatiskt och utan att du behöver skapa och hantera enskilda lagringskonton. Mer information finns i Introduktion till Azure-hanterade diskar
• Använder du ett lagringskonto per kund för dataisolering? I det här scenariot rekommenderar Microsoft att du använder en blobcontainer för varje kund i stället för ett helt lagringskonto. Med Azure Storage kan du nu tilldela Azure-roller per container. Mer information finns i Tilldela en Azure-roll för åtkomst till blobdata.
• 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 ditt program når transaktionsmålet bör du överväga att använda blockbloblagringskonton, som är optimerade för höga transaktionshastigheter och låg och konsekvent svarstid. Mer information finns i kontoöversikten för Azure Storage.
• 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ätverkets prestanda, 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.

Flera klienter har åtkomst till en enskild blob samtidigt

Om du har ett stort antal klienter som har åtkomst till en enda blob samtidigt måste du överväga skalbarhetsmål för både per blob och per lagringskonto. Det exakta antalet klienter som kan komma åt en enskild blob varierar beroende på faktorer som antalet klienter som begär bloben samtidigt, blobens storlek och nätverksvillkor.

Om bloben kan distribueras via ett CDN, till exempel bilder eller videor som hanteras från en webbplats, kan du använda ett CDN. Mer information finns i avsnittet Innehållsdistribution.

I andra scenarier, till exempel vetenskapliga simuleringar där data är konfidentiella, har du två alternativ. Den första är att sprida arbetsbelastningens åtkomst så att bloben nås under en tidsperiod jämfört med att den används samtidigt. Du kan också tillfälligt kopiera bloben till flera lagringskonton för att öka det totala antalet IOPS per blob och mellan lagringskonton. Resultaten varierar beroende på programmets beteende, så se till att testa samtidighetsmönster under designen.

Bandbredd och åtgärder per blob

En enskild blob stöder upp till 500 begäranden per sekund. Om du har flera klienter som behöver läsa samma blob och du kan överskrida den här gränsen kan du överväga att använda ett blockbloblagringskonto. Ett blockbloblagringskonto ger en högre begärandefrekvens eller I/O-åtgärder per sekund (IOPS).

Du kan också använda ett nätverk för innehållsleverans (CDN) som Azure CDN för att distribuera åtgärder på bloben. Mer information om Azure CDN finns i Översikt över Azure CDN.

Partitionering

Att förstå hur Azure Storage partitioner dina blobdata är användbart för att förbättra prestanda. Azure Storage kan hantera data i en enda partition snabbare än data som sträcker sig över flera partitioner. Genom att namnge dina blobar på rätt sätt kan du förbättra effektiviteten för läsbegäranden.

Blob Storage använder ett intervallbaserat partitioneringsschema för skalning och belastningsutjämning. Varje blob har en partitionsnyckel som består av det fullständiga blobnamnet (konto+container+blob). Partitionsnyckeln används för att partitionera blobdata i intervall. Intervallen lastbalanseras sedan över Blob Storage.

Intervallbaserad partitionering innebär att namngivningskonventioner som använder lexikal ordning (till exempel mypayroll, myperformance, myemployees osv.) eller tidsstämplar (log20160101, log20160102, log20160102 osv.) är mer benägna att resultera i att partitionerna samlokaliseras på samma partitionsserver tills ökad belastning kräver att de delas upp i mindre intervall. Att samplacera blobar på samma partitionsserver förbättrar prestandan, så en viktig del av prestandaförbättringen är att namnge blobar på ett sätt som organiserar dem mest effektivt.

Till exempel kan alla blobar i en container hanteras av en enskild server tills belastningen på dessa blobar kräver ytterligare ombalansering av partitionsintervallen. På samma sätt kan en grupp lätt inlästa konton med deras namn ordnade i lexikal ordning hanteras av en enskild server tills belastningen på ett eller alla dessa konton kräver att de delas över flera partitionsservrar.

Varje belastningsutjämningsåtgärd kan påverka svarstiden för lagringsanrop under åtgärden. Tjänstens möjlighet att hantera en plötslig trafiktoppar till en partition begränsas av skalbarheten för en enskild partitionsserver tills belastningsutjämningsåtgärden startar och balanserar om partitionsnyckelintervallet.

Du kan följa några metodtips för att minska frekvensen för sådana åtgärder.

• Använd om möjligt blob- eller blockstorlekar som är större än 256 KiB för standard- och premiumlagringskonton. Större blob- eller blockstorlekar aktiverar automatiskt blockblobar med högt dataflöde. Blockblobar med högt dataflöde ger högpresterande inmatning som inte påverkas av partitionsnamngivning.

• Granska namngivningskonventionen som du använder för konton, containrar, blobar, tabeller och köer. Överväg att prefixera konto-, container- eller blobnamn med en tresiffrig hash med hjälp av en hashfunktion som bäst passar dina behov.

• Om du organiserar dina data med hjälp av tidsstämplar eller numeriska identifierare kontrollerar du att du inte använder ett trafikmönster för endast tillägg (eller endast prepend). Dessa mönster är inte lämpliga för ett intervallbaserat partitioneringssystem. Dessa mönster kan leda till att all trafik går till en enskild partition och begränsar systemet från att effektivt belastningsutjämning.

  Om du till exempel har dagliga åtgärder som använder en blob med en tidsstämpel, till exempel yyyymmdd, dirigeras all trafik för den dagliga åtgärden till en enda blob, som hanteras av en enda partitionsserver. Fundera på om gränserna per blob och gränser per partition uppfyller dina behov och överväg att dela upp åtgärden i flera blobar om det behövs. Om du lagrar tidsseriedata i dina tabeller kan all trafik dirigeras till den sista delen av nyckelnamnområdet. Om du använder numeriska ID:n prefixar du ID:t med en tresiffrig hash. Om du använder tidsstämplar prefixar du tidsstämpeln med sekundvärdet, till exempel ssyyyyymmdd. Om programmet rutinmässigt utför listnings- och frågeåtgärder väljer du en hashningsfunktion som begränsar antalet frågor. I vissa fall kan ett slumpmässigt prefix vara tillräckligt.

• Mer information om partitioneringsschemat som används i Azure Storage finns i Azure Storage: En molnlagringstjänst med hög tillgänglighet med stark konsekvens.

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 NetMon 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.

För bred distribution av blobinnehåll använder du ett nätverk för att leverera innehåll, till exempel Azure CDN. Mer information om Azure CDN finns i Azure CDN.

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.

Cachelagring

Cachelagring spelar en viktig roll i prestanda. I följande avsnitt beskrivs metodtips för cachelagring.

Läsa data

I allmänhet är det bättre att läsa data en gång än att läsa dem två gånger. Överväg exemplet med ett webbprogram som har hämtat en 50 MiB-blob från Azure Storage för att fungera som innehåll för en användare. Helst cachelagrar programmet bloben lokalt till disken och hämtar sedan den cachelagrade versionen för efterföljande användarbegäranden.

Ett sätt att undvika att hämta en blob om den inte har ändrats sedan den cachelagrades är att kvalificera GET-åtgärden med ett villkorsstyrt huvud för ändringstid. Om den senaste ändrade tiden är efter den tid då bloben cachelagrades hämtas blobben och cachelagras igen. Annars hämtas den cachelagrade bloben för optimal prestanda.

Du kan också välja att utforma programmet så att det förutsätter att blobben förblir oförändrad under en kort period efter att den har hämtats. I det här fallet behöver programmet inte kontrollera om bloben ändrades under det intervallet.

Konfigurationsdata, uppslagsdata och andra data som ofta används av programmet är bra kandidater för cachelagring.

Mer information om hur du använder villkorsstyrda rubriker finns i Ange villkorsstyrda huvuden för Blob Service-åtgärder.

Ladda upp data i batchar

I vissa scenarier kan du aggregera data lokalt och sedan regelbundet ladda upp dem i en batch i stället för att ladda upp varje datadel omedelbart. Anta till exempel att ett webbprogram behåller en loggfil med aktiviteter. Programmet kan antingen ladda upp information om varje aktivitet när det händer med en tabell (som kräver många lagringsåtgärder), eller så kan det spara aktivitetsinformation i en lokal loggfil och sedan regelbundet ladda upp all aktivitetsinformation som en avgränsad fil till en blob. Om varje loggpost är 1 KB i storlek kan du ladda upp tusentals poster i en enda transaktion. En enskild transaktion stöder uppladdning av en blob med upp till 64 MiB i storlek. Programutvecklaren måste utforma för risken för klientenheter eller uppladdningsfel. Om aktivitetsdata behöver laddas ned under ett tidsintervall i stället för för en enda aktivitet rekommenderar vi att du använder Blob Storage via Table Storage.

.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

För projekt som använder .NET Framework kan du använda följande kod för att öka standardanslutningsgränsen (som vanligtvis är två i en klientmiljö eller tio 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 en mängd 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.

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. En lista över vanliga felkoder finns i Vanliga REST API-felkoder.

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 felet 503 (Servern är upptagen) eller 500 (tidsgräns). 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 på grund av att 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 försöka igen. 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 (felaktig begäran) anger till exempel att klientprogrammet skickade en begäran som inte kunde bearbetas eftersom den inte var 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.

Kopiera och flytta blobar

Azure Storage tillhandahåller ett antal lösningar för att kopiera och flytta blobar i ett lagringskonto, mellan lagringskonton och mellan lokala system och molnet. I det här avsnittet beskrivs några av dessa alternativ när det gäller deras inverkan på prestanda. Information om hur du effektivt överför data till eller från Blob Storage finns i Välj en Azure-lösning för dataöverföring.

API:er för blobkopiering

Om du vill kopiera blobar mellan lagringskonton använder du åtgärden Placera blockera från URL . Den här åtgärden kopierar data synkront från en URL-källa till en blockblob. Om du använder åtgärden Put Block from URL kan du avsevärt minska den bandbredd som krävs när du migrerar data mellan lagringskonton. Eftersom kopieringsåtgärden sker på tjänstsidan behöver du inte ladda ned och ladda upp data igen.

Om du vill kopiera data inom samma lagringskonto använder du åtgärden Kopiera blob . Kopiering av data inom samma lagringskonto slutförs vanligtvis snabbt.

Använda AzCopy

Kommandoradsverktyget AzCopy är ett enkelt och effektivt alternativ för massöverföring av blobar till, från och mellan lagringskonton. AzCopy är optimerat för det här scenariot och kan uppnå höga överföringshastigheter. AzCopy version 10 använder åtgärden Put Block From URL för att kopiera blobdata mellan lagringskonton. Mer information finns i Kopiera eller flytta data till Azure Storage med hjälp av AzCopy v10.

Använda Azure Data Box

Om du vill importera stora mängder data till Blob Storage bör du överväga att använda Azure Data Box-familjen för offlineöverföringar. Data Box-enheter från Microsoft är ett bra val för att flytta stora mängder data till Azure när du är begränsad av tid, nätverkstillgänglighet eller kostnader. Mer information finns i Dokumentation om Azure DataBox.

Innehållsdistribution

Ibland måste ett program hantera samma innehåll för många användare (till exempel en produktdemovideo som används på startsidan för en webbplats), som finns i samma eller flera regioner. I det här scenariot använder du ett CONTENT Delivery Network (CDN) som Azure Front Door. Azure Front Door är Microsofts moderna moln-CDN som ger snabb, tillförlitlig och säker åtkomst mellan dina användare och programmens statiska och dynamiska webbinnehåll över hela världen. Azure Front Door levererar ditt Blob Storage-innehåll med hjälp av Microsofts globala gränsnätverk med hundratals globala och lokala närvaropunkter (PoPs). Ett CDN kan vanligtvis ha stöd för mycket högre utgående gränser än ett enda lagringskonto och ger bättre svarstid för innehållsleverans till andra regoins.

Mer information om Azure Front Door finns i Azure Front Door.

Använda metadata

Blob-tjänsten stöder HEAD-begäranden, som kan innehålla blobegenskaper eller metadata. Om ditt program till exempel behöver Exif-data (utbytbart bildformat) från ett foto kan det hämta fotot och extrahera det. För att spara bandbredd och förbättra prestandan kan ditt program lagra Exif-data i blobens metadata när programmet laddar upp fotot. Du kan sedan hämta Exif-data i metadata med endast en HEAD-begäran. Om du bara hämtar metadata och inte hela innehållet i blobben sparas betydande bandbredd och den bearbetningstid som krävs för att extrahera Exif-data minskar. Tänk på att 8 KiB-metadata kan lagras per blob.

Uppdateringar av konto- och containermetadata

Konto- och containermetadata sprids över lagringstjänsten i den region där kontot finns. Fullständig spridning av dessa metadata kan ta upp till 60 sekunder beroende på åtgärden. Till exempel:

• Om du snabbt skapar, tar bort och återskapar konton med samma kontonamn i samma region ser du till att du väntar 60 sekunder på att kontotillståndet ska spridas helt eller att dina begäranden misslyckas.
• När du upprättar en lagrad åtkomstprincip på en container kan det ta upp till 30 sekunder innan principen börjar gälla.

Prestandajustering för dataöverföringar

När ett program överför data med hjälp av Azure Storage-klientbiblioteket finns det flera faktorer som kan påverka hastighet, minnesanvändning och till och med lyckade eller misslyckade begäranden. För att maximera prestanda och tillförlitlighet för dataöverföringar är det viktigt att vara proaktiv när det gäller att konfigurera överföringsalternativ för klientbibliotek baserat på den miljö som appen körs i. Mer information finns i Prestandajustering för uppladdningar och nedladdningar.

Ladda upp blobar snabbt

Om du vill ladda upp blobar snabbt ska du först avgöra om du laddar upp en blob eller många. Använd vägledningen nedan för att fastställa rätt metod att använda beroende på ditt scenario. Om du använder Azure Storage-klientbiblioteket för dataöverföringar kan du läsa Prestandajustering för dataöverföringar för ytterligare vägledning.

Ladda upp en stor blob snabbt

Om du snabbt vill ladda upp en enda stor blob kan ett klientprogram ladda upp sina block eller sidor parallellt, med tanke på skalbarhetsmålen för enskilda blobar och lagringskontot som helhet. Azure Storage-klientbiblioteken stöder uppladdning parallellt. Klientbibliotek för andra språk som stöds har liknande alternativ.

Ladda upp många blobar snabbt

Om du vill ladda upp många blobar snabbt laddar du upp blobar parallellt. Uppladdning parallellt är snabbare än att ladda upp enskilda blobar i taget med parallella blockuppladdningar eftersom det sprider uppladdningen över flera partitioner i lagringstjänsten. AzCopy utför uppladdningar parallellt som standard och rekommenderas för det här scenariot. Mer information finns i Komma igång med AzCopy.

Välj rätt typ av blob

Azure Storage stöder blockblobar, tilläggsblobar och sidblobar. För ett givet användningsscenario påverkar ditt val av blobtyp lösningens prestanda och skalbarhet.

Blockblobar är lämpliga när du vill ladda upp stora mängder data effektivt. Ett klientprogram som laddar upp foton eller video till Blob Storage skulle till exempel rikta in sig på blockblobar.

Tilläggsblobar liknar blockblobar eftersom de består av block. När du ändrar en tilläggsblob läggs endast block till i slutet av bloben. Tilläggsblobar är användbara för scenarier som loggning, när ett program behöver lägga till data i en befintlig blob.

Sidblobar är lämpliga om programmet behöver utföra slumpmässiga skrivningar på data. Till exempel lagras virtuella Azure-datordiskar som sidblobar. Mer information finns i Förstå blockblobar, tilläggsblobar och sidblobar.

Nästa steg

• Skalbarhets- och prestandamål för Blob Storage
• Skalbarhets- och prestandamål för standardlagringskonton
• Status- och felkoder