Controlelijst voor prestaties en schaalbaarheid voor Blob-opslag
Microsoft heeft een aantal bewezen procedures ontwikkeld voor het ontwikkelen van hoogwaardige toepassingen met Blob Storage. Deze controlelijst vermeldt de belangrijkste procedures die ontwikkelaars kunnen volgen om de prestaties te optimaliseren. Houd rekening met deze procedures tijdens het ontwerpen van uw toepassing en tijdens het hele proces.
Azure Storage bevat schaalbaarheids- en prestatiedoelen voor capaciteit, transactiesnelheid en bandbreedte. Zie Schaalbaarheids- en prestatiedoelen voor standaardopslagaccounts en schaalbaarheids- en prestatiedoelen voor Blob Storage voor meer informatie over schaalbaarheidsdoelen voor Azure Storage.
Checklijst
In dit artikel vindt u bewezen procedures voor prestaties in een controlelijst die u kunt volgen tijdens het ontwikkelen van uw Blob Storage-toepassing.
Schaalbaarheidsdoelen
Als uw toepassing een van de schaalbaarheidsdoelen benadert of overschrijdt, kunnen er meer latenties in of beperkingen voor transacties optreden. Wanneer Azure Storage uw toepassing beperkt, begint de service met het retourneren van de foutcodes 503 (server bezet) of 500 (time-out voor bewerking). Het vermijden van deze fouten door binnen de grenzen van de schaalbaarheidsdoelen te blijven vormt een belangrijk onderdeel van het verbeteren van de prestaties van uw toepassing.
Zie Schaalbaarheids- en prestatiedoelen voor Azure Storage voor meer informatie over de schaalbaarheidsdoelen voor de Queue-service.
Maximum aantal opslagaccounts
Als u het maximum aantal opslagaccounts nadert dat is toegestaan voor een bepaalde combinatie van abonnementen/regio's, evalueert u uw scenario en bepaalt u of een van de volgende voorwaarden van toepassing is:
- Gebruikt u opslagaccounts om niet-beheerde schijven op te slaan en deze schijven toe te voegen aan uw virtuele machines (VM's)? Voor dit scenario raadt Microsoft het gebruik van beheerde schijven aan. Beheerde schijven worden automatisch en zonder dat u afzonderlijke opslagaccounts hoeft te maken en beheren. Zie Inleiding tot beheerde Azure-schijven voor meer informatie
- Gebruikt u één opslagaccount per klant voor gegevensisolatie? Voor dit scenario raadt Microsoft aan om voor elke klant een blobcontainer te gebruiken in plaats van een volledig opslagaccount. Met Azure Storage kunt u nu Azure-rollen per container toewijzen. Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie.
- Gebruikt u meerdere opslagaccounts voor shard om inkomend, uitgaand verkeer, I/O-bewerkingen per seconde (IOPS) of capaciteit te verhogen? In dit scenario raadt Microsoft u aan gebruik te maken van verhoogde limieten voor opslagaccounts om zo mogelijk het aantal opslagaccounts te beperken dat is vereist voor uw workload. Neem contact op met Ondersteuning voor Azure om verhoogde limieten voor uw opslagaccount aan te vragen.
Capaciteits- en transactiedoelen
Als uw toepassing de schaalbaarheidsdoelen voor één opslagaccount nadert, kunt u een van de volgende benaderingen overwegen:
- Als uw toepassing het transactiedoel bereikt, kunt u overwegen om blok-blobopslagaccounts te gebruiken, die zijn geoptimaliseerd voor hoge transactiesnelheden en lage en consistente latentie. Zie Overzicht van Azure-opslagaccount voor meer informatie.
- Bekijk de workload die ervoor zorgt dat uw toepassing het schaalbaarheidsdoel benadert of overschrijdt. Kunt u het op een andere manier ontwerpen waardoor u minder bandbreedte of capaciteit of minder transacties gebruikt?
- Als uw toepassing een van de schaalbaarheidsdoelen moet overschrijden, maakt u meerdere opslagaccounts en partitioneert u uw toepassingsgegevens over deze meerdere opslagaccounts. Als u dit patroon gebruikt, moet u ervoor zorgen dat u uw toepassing zo ontwerpt, dat u in de toekomst meer opslagaccounts kunt toevoegen voor de taakverdeling. Opslagaccounts zelf hebben geen andere kosten dan uw gebruik in termen van opgeslagen gegevens, gemaakte transacties of overgedragen gegevens.
- Als uw toepassing de bandbreedtedoelen nadert, kunt u de gegevens aan de clientzijde comprimeren om de bandbreedte te verminderen die nodig is om de gegevens naar Azure Storage te verzenden. Hoewel met het comprimeren van gegevens bandbreedte kan worden bespaard en de netwerkprestaties worden verbeterd, kan dit ook negatieve gevolgen voor de prestaties hebben. Evalueer de invloed op de prestaties van de extra verwerkingsvereisten voor de compressie en decompressie van gegevens aan de clientzijde. Houd er rekening mee dat het door het opslaan van gecomprimeerde gegevens lastiger wordt om problemen op te lossen, aangezien het lastiger kan zijn om de gegevens te bekijken met behulp van standaardhulpprogramma's.
- Als uw toepassing de schaalbaarheidsdoelen nadert, moet u ervoor zorgen dat u een exponentieel uitstel gebruikt voor nieuwe pogingen. U kunt het beste voorkomen dat u de schaalbaarheidsdoelen bereikt door de aanbevelingen te implementeren die in dit artikel worden beschreven. Als u echter een exponentieel uitstel gebruikt voor nieuwe pogingen, voorkomt u dat uw toepassing snel opnieuw probeert, waardoor de beperking slechter kan worden. Zie de sectie met de titel Time-out- en server-bezetfouten voor meer informatie.
Meerdere clients die gelijktijdig toegang hebben tot één blob
Als u een groot aantal clients hebt die gelijktijdig toegang hebben tot één blob, moet u rekening houden met schaalbaarheidsdoelen per blob en per opslagaccount. Het exacte aantal clients dat toegang heeft tot één blob, is afhankelijk van factoren zoals het aantal clients dat tegelijkertijd de blob aanvraagt, de grootte van de blob en netwerkvoorwaarden.
Als de blob kan worden gedistribueerd via een CDN, zoals afbeeldingen of video's van een website, kunt u een CDN gebruiken. Zie de sectie Inhoudsdistributie voor meer informatie.
In andere scenario's, zoals wetenschappelijke simulaties waarbij de gegevens vertrouwelijk zijn, hebt u twee opties. Het eerste is om de toegang van uw werkbelasting te s stagneren, zodat de blob gedurende een bepaalde periode wordt geopend en tegelijkertijd wordt geopend. U kunt de blob ook tijdelijk kopiëren naar meerdere opslagaccounts om de totale IOPS per blob en tussen opslagaccounts te verhogen. De resultaten variëren, afhankelijk van het gedrag van uw toepassing, dus zorg ervoor dat u gelijktijdigheidspatronen test tijdens het ontwerp.
Bandbreedte en bewerkingen per blob
Eén blob ondersteunt maximaal 500 aanvragen per seconde. Als u meerdere clients hebt die dezelfde blob moeten lezen en u deze limiet mogelijk overschrijdt, kunt u overwegen om een blok-blobopslagaccount te gebruiken. Een blok-blob-opslagaccount biedt een hogere aanvraagsnelheid of I/O-bewerkingen per seconde (IOPS).
U kunt ook een netwerk voor contentlevering (CDN) zoals Azure CDN gebruiken om bewerkingen op de blob te distribueren. Zie het overzicht van Azure CDN voor meer informatie over Azure CDN.
Partitionering
Inzicht in hoe Azure Storage uw blobgegevens partitioneert, is handig voor het verbeteren van de prestaties. Azure Storage kan gegevens in één partitie sneller verwerken dan gegevens die meerdere partities omvatten. Door uw blobs de juiste naam te geven, kunt u de efficiëntie van leesaanvragen verbeteren.
Blob Storage maakt gebruik van een partitieschema op basis van een bereik voor schalen en taakverdeling. Elke blob heeft een partitiesleutel die bestaat uit de volledige blobnaam (account+container+blob). De partitiesleutel wordt gebruikt om blobgegevens te partitioneren in bereiken. De bereiken worden vervolgens verdeeld over Blob Storage.
Partitionering op basis van bereik betekent dat naamconventies die gebruikmaken van lexicale volgorde (bijvoorbeeld mypayroll, myperformance, myemployees, enzovoort) of tijdstempels (log20160101, log20160102, log20160102, enzovoort) waarschijnlijk leiden tot co-locatie van de partities op dezelfde partitieserver totdat de belasting toeneemt dat ze worden gesplitst in kleinere bereiken. Co-locing van blobs op dezelfde partitieserver verbetert de prestaties, dus een belangrijk onderdeel van prestatieverbetering omvat het benoemen van blobs op een manier die ze het effectiefst organiseert.
Alle blobs in een container kunnen bijvoorbeeld door één server worden bediend totdat de belasting van deze blobs verder moet worden verdeeld over de partitiebereiken. Op dezelfde manier kan een groep licht geladen accounts met hun namen in lexicale volgorde worden bediend door één server totdat de belasting van een of al deze accounts vereist dat ze worden gesplitst over meerdere partitieservers.
Elke taakverdelingsbewerking kan van invloed zijn op de latentie van opslagoproepen tijdens de bewerking. De mogelijkheid van de service om een plotselinge burst van verkeer naar een partitie af te handelen, wordt beperkt door de schaalbaarheid van één partitieserver totdat de taakverdelingsbewerking wordt geactiveerd en het partitiesleutelbereik opnieuw wordt verdeeld.
U kunt enkele aanbevolen procedures volgen om de frequentie van dergelijke bewerkingen te verminderen.
Gebruik indien mogelijk blob- of blokgrootten die groter zijn dan 256 KiB voor standard- en Premium-opslagaccounts. Grotere blob- of blokgrootten activeren blok-blobs met hoge doorvoer automatisch. Blok-blobs met hoge doorvoer bieden high-performance opname die niet wordt beïnvloed door naamgeving van partities.
Bekijk de naamgevingsconventie die u gebruikt voor accounts, containers, blobs, tabellen en wachtrijen. Overweeg de namen van accounts, containers of blobs te laten voorafgaan door een hash van drie cijfers met behulp van een hashfunctie die het beste bij uw behoeften past.
Als u uw gegevens indeelt met behulp van tijdstempels of numerieke id's, moet u ervoor zorgen dat u geen alleen-toevoegverkeerspatroon (of alleen-alleen-toevoegen) gebruikt. Deze patronen zijn niet geschikt voor een partitioneringssysteem op basis van een bereik. Deze patronen kunnen ertoe leiden dat al het verkeer naar één partitie gaat en het systeem beperk tegen effectieve taakverdeling.
Als u bijvoorbeeld dagelijkse bewerkingen hebt die gebruikmaken van een blob met een tijdstempel zoals jjjjmmdd, wordt al het verkeer voor die dagelijkse bewerking omgeleid naar één blob, die wordt geleverd door één partitieserver. Overweeg of de limieten per blob en per partitie voldoen aan uw behoeften en overweeg deze bewerking indien nodig in meerdere blobs te verdelen. Als u tijdreeksgegevens in uw tabellen opslaat, kan al het verkeer worden omgeleid naar het laatste deel van de sleutelnaamruimte. Als u numerieke id's gebruikt, moet u de id vooraf laten gaan door een hash van drie cijfers. Als u tijdstempels gebruikt, moet u het tijdstempel vooraf laten gaan door de waarde seconden, bijvoorbeeld ssyyyymmdd. Als uw toepassing regelmatig vermeldings- en querybewerkingen uitvoert, kiest u een hashfunctie waarmee uw aantal query's wordt beperkt. In sommige gevallen kan een willekeurig voorvoegsel voldoende zijn.
Zie Azure Storage: Een maximaal beschikbare cloudopslagservice met sterke consistentie voor meer informatie over het partitioneringsschema dat wordt gebruikt in Azure Storage.
Netwerken
De beperkingen van het fysieke netwerk van de toepassing kunnen een grote invloed hebben op de prestaties. In de volgende secties worden enkele beperkingen beschreven die gebruikers kunnen tegenkomen.
Netwerkmogelijkheden van de client
De bandbreedte en de kwaliteit van de netwerkkoppeling spelen een belangrijke rol in prestaties van toepassingen, zoals beschreven in de volgende secties.
Doorvoer
Voor bandbreedte is het probleem vaak de mogelijkheden van de client. Grotere Azure-exemplaren hebben NIC's met een grotere capaciteit. U moet dus overwegen een grotere exemplaar of meer VM's te gebruiken als u hogere netwerklimieten voor één computer nodig hebt. Als u toegang hebt tot Azure Storage vanuit een on-premises toepassing, is dezelfde regel van toepassing: inzicht in de netwerkmogelijkheden van het clientapparaat en de netwerkverbinding met de Azure Storage-locatie en verbeter deze indien nodig of ontwerp uw toepassing om binnen hun mogelijkheden te werken.
Kwaliteit van de koppeling
Houd er net als bij elk netwerkgebruik rekening mee dat netwerkomstandigheden die resulteren in fouten en pakketverlies de effectieve doorvoer vertraagt. Het gebruik van WireShark of NetMon kan helpen bij het vaststellen van dit probleem.
Locatie
Wanneer u de client dicht bij de server plaatst, levert dit in een gedistribueerde omgeving de beste prestaties op. Als u toegang wilt tot Azure Storage met de laagste latentie, bevindt de beste locatie voor uw client zich in dezelfde Azure-regio. Als u bijvoorbeeld een Azure-web-app hebt die gebruikmaakt van Azure Storage, plaatst u deze beide binnen één regio, zoals US - west of Azië - zuidoost. Wanneer u resources bij elkaar plaatst, vermindert u de latentie en de kosten, omdat het bandbreedtegebruik binnen één regio gratis is.
Als clienttoepassingen toegang hebben tot Azure Storage, maar niet worden gehost in Azure, zoals apps voor mobiele apparaten of on-premises bedrijfsservices, kan het zoeken van het opslagaccount in een regio in de buurt van die clients de latentie verminderen. Als uw clients breed worden gedistribueerd (bijvoorbeeld sommige in Noord-Amerika en sommige in Europa), kunt u een opslagaccount per regio gebruiken. Deze aanpak is eenvoudiger te implementeren als de gegevens die in de toepassingsarchieven worden opgeslagen specifiek zijn voor afzonderlijke gebruikers en geen gegevens hoeven te worden gerepliceerd tussen opslagaccounts.
Voor een brede distributie van blob-inhoud gebruikt u een netwerk voor het leveren van inhoud, zoals Azure CDN. Zie Azure CDN voor meer informatie over Azure CDN.
SAS en CORS
Stel dat u code moet machtigen zoals JavaScript dat wordt uitgevoerd in de webbrowser van een gebruiker of in een app op een mobiele telefoon om toegang te krijgen tot gegevens in Azure Storage. Een aanpak is om een servicetoepassing te compileren die als een proxy fungeert. Het apparaat van de gebruiker wordt geverifieerd bij de service, die op zijn beurt toegang tot Azure Storage-resources verleent. Op deze manier kunt u voorkomen dat de sleutels van uw opslagaccount op onveilige apparaten worden weergegeven. Met deze benadering wordt echter een aanzienlijke overhead op de servicetoepassing geplaatst, omdat alle gegevens die worden overgedragen tussen het apparaat van de gebruiker en Azure Storage via de servicetoepassing moeten worden doorgegeven.
U kunt voorkomen dat een servicetoepassing wordt gebruikt als een proxy voor Azure Storage met behulp van Shared Access Signatures (SAS). Met SAS kunt u het apparaat van uw gebruiker in staat stellen om aanvragen rechtstreeks bij Azure Storage in te dienen met behulp van een beperkt toegangstoken. Als een gebruiker bijvoorbeeld een foto wil uploaden naar uw toepassing, kan uw servicetoepassing een SAS genereren en deze verzenden naar het apparaat van de gebruiker. Het SAS-token kan toestemming geven om naar een Azure Storage-resource te schrijven gedurende een opgegeven tijdsinterval, waarna het SAS-token verloopt. Zie Beperkte toegang verlenen tot Azure Storage-resources via SAS (Shared Access Signatures) voor meer informatie over SAS.
Normaal gesproken staat een webbrowser JavaScript niet toe op een pagina die wordt gehost door een website op het ene domein om bepaalde bewerkingen, zoals schrijfbewerkingen, uit te voeren naar een ander domein. Op basis van dit beleid, dat bekend staat als 'beleid voor zelfde oorsprong', wordt voorkomen dat een schadelijk script op één pagina de toegang tot gegevens op een andere webpagina kan verkrijgen. Hetzelfde 'beleid voor zelfde oorsprong' kan echter een beperking zijn bij het compileren van een oplossing in de cloud. Cross-Origin Resource Sharing (CORS) is een browserfunctie waarmee het doeldomein van het brondomein afkomstige aanvragen kan doorgeven aan een vertrouwde browser.
Stel bijvoorbeeld dat een webtoepassing die in Azure wordt uitgevoerd een aanvraag voor een resource indient bij een Azure Storage-account. De webtoepassing is het brondomein en het opslagaccount is het doeldomein. U kunt CORS voor elk van de Azure Storage-services configureren om met de webbrowser aanvragen door te geven vanuit het brondomein dat worden vertrouwd door Azure Storage. Zie CORS-ondersteuning (cross-origin resource sharing) voor Azure Storage voor meer informatie over CORS.
Met SAS en CORS kunt u voorkomen dat uw webtoepassing onnodig wordt belast.
Caching
Caching speelt een belangrijke rol in prestaties. In de volgende secties worden aanbevolen procedures voor caching besproken.
Lezen van de gegevens
Over het algemeen is het lezen van gegevens eenmaal de voorkeur om deze twee keer te lezen. Bekijk het voorbeeld van een webtoepassing die een 50 MiB-blob heeft opgehaald uit Azure Storage om te fungeren als inhoud voor een gebruiker. Idealiter slaat de toepassing de blob lokaal op de schijf op en haalt de versie in de cache op voor volgende gebruikersaanvragen.
Een manier om te voorkomen dat een blob wordt opgehaald als deze niet is gewijzigd omdat deze in de cache is opgeslagen, is om de GET-bewerking te kwalificeren met een voorwaardelijke header voor wijzigingstijd. Als de laatste wijzigingstijd valt na de tijd dat de blob in de cache is opgeslagen, wordt de blob opgehaald en opnieuw in de cache opgeslagen. Anders wordt de blob in de cache opgehaald voor optimale prestaties.
U kunt ook besluiten om uw toepassing te ontwerpen om ervan uit te gaan dat de blob gedurende een korte periode ongewijzigd blijft na het ophalen ervan. In dit geval hoeft de toepassing niet te controleren of de blob tijdens dat interval is gewijzigd.
Configuratiegegevens, opzoekgegevens en andere gegevens die vaak door de toepassing worden gebruikt, zijn goede kandidaten voor caching.
Zie Voorwaardelijke headers opgeven voor blobservicebewerkingen voor meer informatie over het gebruik van voorwaardelijke headers.
Gegevens uploaden in batches
In sommige scenario's kunt u gegevens lokaal aggregeren en deze vervolgens periodiek uploaden in een batch in plaats van elk stukje gegevens onmiddellijk te uploaden. Stel dat een webtoepassing een logboekbestand met activiteiten bewaart. De toepassing kan details van elke activiteit uploaden zoals deze gebeurt met een tabel (waarvoor veel opslagbewerkingen vereist zijn), of kan activiteitsgegevens opslaan in een lokaal logboekbestand en vervolgens periodiek alle activiteitsgegevens uploaden als een bestand met scheidingstekens naar een blob. Als elke logboekvermelding 1 kB groot is, kunt u duizenden vermeldingen uploaden in één transactie. Eén transactie ondersteunt het uploaden van een blob van maximaal 64 MiB in grootte. De ontwikkelaar van de toepassing moet ontwerpen voor de mogelijkheid van fouten bij het uploaden van clientapparaten of uploadfouten. Als de activiteitsgegevens gedurende een bepaalde periode moeten worden gedownload in plaats van voor één activiteit, wordt het gebruik van Blob Storage aanbevolen via Table Storage.
.NET-configuratie
Voor projecten die .NET Framework gebruiken, worden in deze sectie enkele snelle configuratie-instellingen vermeld die u kunt gebruiken om aanzienlijke prestatieverbeteringen aan te brengen. Als u een andere taal dan .NET gebruikt, controleert u of vergelijkbare concepten van toepassing zijn in de gekozen taal.
De standaardverbindingslimiet verhogen
Notitie
Deze sectie is van toepassing op projecten die gebruikmaken van .NET Framework, omdat groepsgewijze verbindingen worden beheerd door de ServicePointManager-klasse. .NET Core heeft een aanzienlijke wijziging in het beheer van verbindingsgroepen geïntroduceerd, waarbij verbindingspooling plaatsvindt op httpClient-niveau en de poolgrootte niet standaard wordt beperkt. Dit betekent dat HTTP-verbindingen automatisch worden geschaald om te voldoen aan uw workload. Het gebruik van de nieuwste versie van .NET wordt, indien mogelijk, aanbevolen om te profiteren van prestatieverbeteringen.
Voor projecten die .NET Framework gebruiken, kunt u de volgende code gebruiken om de standaardverbindingslimiet (meestal twee in een clientomgeving of tien in een serveromgeving) te verhogen tot 100. Normaal gesproken moet u de waarde instellen op ongeveer het aantal threads dat door uw toepassing wordt gebruikt. Stel de verbindingslimiet in voordat u verbindingen opent.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Zie de documentatie voor andere programmeertalen om te bepalen hoe de verbindingslimiet moet worden ingesteld.
Minimumaantal threads verhogen
Als u synchrone aanroepen samen met asynchrone taken gebruikt, kunt u het aantal threads in de threadpool verhogen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Zie de methode ThreadPool.SetMinThreads voor meer informatie.
Niet-gebonden parallelle uitvoering
Hoewel parallelle uitvoering handig kan zijn voor prestaties, moet u voorzichtig zijn met het gebruik van niet-afhankelijke parallelle uitvoering, wat betekent dat er geen limiet is afgedwongen voor het aantal threads of parallelle aanvragen. Zorg ervoor dat u parallelle aanvragen beperkt tot het uploaden of downloaden van gegevens, om toegang te krijgen tot meerdere partities in hetzelfde opslagaccount of om toegang te krijgen tot meerdere items in dezelfde partitie. Als parallelle uitvoering niet is gebonden, kan uw toepassing de mogelijkheden van het clientapparaat of de schaalbaarheidsdoelen van het opslagaccount overschrijden, wat resulteert in langere latenties en bandbreedtebeperking.
Clientbibliotheken en hulpprogramma's
Gebruik altijd de nieuwste clientbibliotheken en hulpprogramma's van Microsoft voor de beste prestaties. Azure Storage-clientbibliotheken zijn beschikbaar in diverse talen. Azure Storage biedt ook ondersteuning voor PowerShell en Azure CLI. Microsoft ontwikkelt deze clientbibliotheken en hulpprogramma's actief met het oog op de prestaties, houdt ze up-to-date met de nieuwste serviceversies en zorgt ervoor dat ze een groot aantal van de bewezen uitvoeringspraktijken intern verwerken.
Tip
Het ABFS-stuurprogramma is ontworpen om de inherente tekortkomingen van WASB te overwinnen. Microsoft raadt aan om het ABFS-stuurprogramma via het WASB-stuurprogramma te gebruiken, omdat het ABFS-stuurprogramma speciaal is geoptimaliseerd voor big data-analyses.
Servicefouten afhandelen
Azure Storage retourneert een fout wanneer de service een aanvraag niet kan verwerken. Voor het optimaliseren van de prestaties is het handig om inzicht te hebben in de fouten die door Azure Storage in een bepaald scenario kunnen worden geretourneerd. Zie Algemene REST API-foutcodes voor een lijst met veelvoorkomende foutcodes.
Time-out- en server-bezetfouten
Azure Storage kan uw toepassing beperken als deze de schaalbaarheidslimieten nadert. In sommige gevallen kan Azure Storage mogelijk geen aanvragen verwerken vanwege een tijdelijke omstandigheid. In beide gevallen kan de service de fout 503 (server bezet) of 500 (time-out) retourneren. Deze fouten kunnen zich ook voordoen als de service gegevenspartities opnieuw moet verdelen voor een hogere doorvoer. De clienttoepassing moet meestal de bewerking opnieuw uitvoeren die een van deze fouten heeft veroorzaakt. Als Azure Storage uw toepassing echter beperkt omdat deze de schaalbaarheidsdoelen overschrijdt, of zelfs als de service de aanvraag om een andere reden niet kon verwerken, kunnen agressieve nieuwe pogingen het probleem verergeren. Het gebruik van een beleid voor opnieuw proberen met exponentieel uitstel wordt aanbevolen. De clientbibliotheken zijn standaard ingesteld op dit gedrag. Uw toepassing kan bijvoorbeeld na 2 seconden een nieuwe poging doen, daarna na 4 seconden, daarna na 10 seconden, daarna na 30 seconden, en vervolgens volledig opgeven. Op deze manier vermindert uw toepassing de belasting van de service aanzienlijk, in plaats van verergerend gedrag te vertonen dat kan leiden tot aanvraagbeperking.
Connectiviteitsfouten kunnen onmiddellijk opnieuw worden geprobeerd, omdat ze niet het gevolg zijn van beperking en naar verwachting tijdelijk zijn.
Fouten waarbij geen nieuwe pogingen mogelijk zijn
De clientbibliotheken verwerken nieuwe pogingen met een inzicht in welke fouten opnieuw kunnen worden geprobeerd en welke niet opnieuw kunnen worden geprobeerd. Als u de Azure Storage REST API echter rechtstreeks aanroept, zijn er enkele fouten die u niet opnieuw moet proberen. Een 400-fout (ongeldige aanvraag) geeft bijvoorbeeld aan dat de clienttoepassing een aanvraag heeft verzonden die niet kan worden verwerkt omdat deze niet in het verwachte formulier stond. Het opnieuw verzenden van deze aanvraag resulteert elke keer in hetzelfde antwoord, dus er is geen punt om het opnieuw te proberen. Als u de Azure Storage REST API rechtstreeks aanroept, moet u op de hoogte zijn van mogelijke fouten en of ze opnieuw moeten worden geprobeerd.
Zie Status en foutcodes voor meer informatie over Azure Storage-foutcodes.
Blobs kopiëren en verplaatsen
Azure Storage biedt een aantal oplossingen voor het kopiëren en verplaatsen van blobs binnen een opslagaccount, tussen opslagaccounts en tussen on-premises systemen en de cloud. In deze sectie worden enkele van deze opties beschreven in termen van hun gevolgen voor prestaties. Zie Een Azure-oplossing voor gegevensoverdracht kiezen voor gegevensoverdracht voor informatie over het efficiënt overdragen van gegevens naar of van Blob Storage.
Blob-api's kopiëren
Als u blobs tussen opslagaccounts wilt kopiëren, gebruikt u de bewerking Put Block From URL . Met deze bewerking worden gegevens synchroon gekopieerd van elke URL-bron naar een blok-blob. Het gebruik van de Put Block from URL bewerking kan de vereiste bandbreedte aanzienlijk verminderen wanneer u gegevens migreert tussen opslagaccounts. Omdat de kopieerbewerking aan de servicezijde plaatsvindt, hoeft u de gegevens niet te downloaden en opnieuw te uploaden.
Als u gegevens in hetzelfde opslagaccount wilt kopiëren, gebruikt u de bewerking Blob kopiëren. Het kopiëren van gegevens binnen hetzelfde opslagaccount wordt doorgaans snel voltooid.
AzCopy gebruiken
Het opdrachtregelprogramma AzCopy is een eenvoudige en efficiënte optie voor bulkoverdracht van blobs naar, van en tussen opslagaccounts. AzCopy is geoptimaliseerd voor dit scenario en kan hoge overdrachtssnelheden bereiken. AzCopy versie 10 gebruikt de Put Block From URL bewerking om blobgegevens te kopiëren tussen opslagaccounts. Zie Gegevens kopiëren of verplaatsen naar Azure Storage met behulp van AzCopy v10 voor meer informatie.
Azure Data Box gebruiken
Voor het importeren van grote hoeveelheden gegevens in Blob Storage kunt u overwegen om de Azure Data Box-serie te gebruiken voor offlineoverdrachten. Door Microsoft geleverde Data Box-apparaten zijn een goede keuze voor het verplaatsen van grote hoeveelheden gegevens naar Azure wanneer u beperkt bent door tijd, netwerkbeschikbaarheid of kosten. Zie de documentatie voor Azure DataBox voor meer informatie.
Inhoudsdistributie
Soms moet een toepassing dezelfde inhoud leveren aan veel gebruikers (bijvoorbeeld een productdemovideo die wordt gebruikt op de startpagina van een website), die zich in dezelfde of meerdere regio's bevindt. In dit scenario gebruikt u een CDN (Content Delivery Network), zoals Azure Front Door. Azure Front Door is het moderne cloud-CDN van Microsoft dat snelle, betrouwbare en veilige toegang biedt tussen uw gebruikers en de statische en dynamische webinhoud van uw toepassingen over de hele wereld. Azure Front Door levert uw Blob Storage-inhoud met behulp van het wereldwijde edge-netwerk van Microsoft met honderden wereldwijde en lokale aanwezigheidspunten (PoPs). Een CDN kan doorgaans veel hogere uitgaande limieten ondersteunen dan één opslagaccount en biedt verbeterde latentie voor het leveren van inhoud aan andere nieuwe aanmeldingen.
Zie Azure Front Door voor meer informatie over Azure Front Door.
Metagegevens gebruiken
De Blob-service ondersteunt HEAD-aanvragen, die blobeigenschappen of metagegevens kunnen bevatten. Als uw toepassing bijvoorbeeld de Exif-gegevens (uitwisselbare afbeeldingsindeling) van een foto nodig heeft, kan deze de foto ophalen en extraheren. Om bandbreedte te besparen en de prestaties te verbeteren, kan uw toepassing de Exif-gegevens opslaan in de metagegevens van de blob wanneer de toepassing de foto uploadt. Vervolgens kunt u de Exif-gegevens in metagegevens ophalen met behulp van alleen een HEAD-aanvraag. Het ophalen van alleen metagegevens en niet de volledige inhoud van de blob bespaart aanzienlijke bandbreedte en vermindert de verwerkingstijd die nodig is om de Exif-gegevens te extraheren. Houd er rekening mee dat 8 KiB van metagegevens per blob kan worden opgeslagen.
Updates voor account- en containermetagegevens
Metagegevens van accounts en containers worden doorgegeven in de opslagservice in de regio waarin het account zich bevindt. De volledige doorgifte van deze metagegevens kan tot 60 seconden duren, afhankelijk van de bewerking. Voorbeeld:
- Als u snel accounts maakt, verwijdert en opnieuw maakt met dezelfde accountnaam in dezelfde regio, zorgt u ervoor dat u 60 seconden wacht totdat de accountstatus volledig is doorgegeven of uw aanvragen mislukken.
- Wanneer u een opgeslagen toegangsbeleid instelt voor een container, kan het tot 30 seconden duren voordat het beleid van kracht wordt.
Prestaties afstemmen voor gegevensoverdracht
Wanneer een toepassing gegevens overdraagt met behulp van de Azure Storage-clientbibliotheek, zijn er verschillende factoren die van invloed kunnen zijn op snelheid, geheugengebruik en zelfs het slagen of mislukken van de aanvraag. Om de prestaties en betrouwbaarheid voor gegevensoverdracht te maximaliseren, is het belangrijk om proactief te zijn bij het configureren van opties voor clientbibliotheekoverdracht op basis van de omgeving waarin uw app wordt uitgevoerd. Zie Prestaties afstemmen voor uploads en downloads voor meer informatie.
Snel blobs uploaden
Als u snel blobs wilt uploaden, moet u eerst bepalen of u één blob of veel uploadt. Gebruik de onderstaande richtlijnen om de juiste methode te bepalen die u wilt gebruiken, afhankelijk van uw scenario. Als u de Azure Storage-clientbibliotheek gebruikt voor gegevensoverdracht, raadpleegt u Prestaties afstemmen voor gegevensoverdracht voor verdere richtlijnen.
Snel één grote blob uploaden
Als u één grote blob snel wilt uploaden, kan een clienttoepassing de blokken of pagina's parallel uploaden, waarbij rekening wordt gehouden met de schaalbaarheidsdoelen voor afzonderlijke blobs en het opslagaccount als geheel. De Azure Storage-clientbibliotheken ondersteunen het parallel uploaden. Clientbibliotheken voor andere ondersteunde talen bieden vergelijkbare opties.
Veel blobs snel uploaden
Als u snel veel blobs wilt uploaden, uploadt u blobs parallel. Het parallel uploaden is sneller dan het uploaden van één blobs tegelijk met parallelle blokuploads, omdat het uploaden over meerdere partities van de opslagservice verspreidt. AzCopy voert standaard uploads parallel uit en wordt aanbevolen voor dit scenario. Zie Aan de slag met AzCopy voor meer informatie.
Het juiste type blob kiezen
Azure Storage ondersteunt blok-blobs, toevoeg-blobs en pagina-blobs. Voor een bepaald gebruiksscenario is uw keuze van het blobtype van invloed op de prestaties en schaalbaarheid van uw oplossing.
Blok-blobs zijn geschikt wanneer u grote hoeveelheden gegevens efficiënt wilt uploaden. Een clienttoepassing die bijvoorbeeld foto's of video's uploadt naar Blob Storage, is gericht op blok-blobs.
Toevoeg-blobs zijn vergelijkbaar met blok-blobs omdat ze bestaan uit blokken. Wanneer u een toevoeg-blob wijzigt, worden blokken alleen toegevoegd aan het einde van de blob. Toevoeg-blobs zijn handig voor scenario's zoals logboekregistratie wanneer een toepassing gegevens moet toevoegen aan een bestaande blob.
Pagina-blobs zijn geschikt als de toepassing willekeurige schrijfbewerkingen op de gegevens moet uitvoeren. Schijven van virtuele Azure-machines worden bijvoorbeeld opgeslagen als pagina-blobs. Zie Blok-blobs, toevoeg-blobs en pagina-blobs voor meer informatie.