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. Neem bij het ontwerpen van uw toepassing en tijdens het gehele proces deze procedures in acht.

Azure Storage bevat schaalbaarheids- en prestatiedoelen voor capaciteit, transactiesnelheid en bandbreedte. Zie Schaalbaarheids- en prestatiedoelen voor standaardopslagaccounts enSchaalbaarheids- en prestatiedoelen voor Blob Storage voor meer informatie over schaalbaarheidsdoelen voor Azure Storage.

Controlelijst

In dit artikel worden bewezen procedures voor prestaties in een controlelijst ingedeeld die u kunt volgen tijdens het ontwikkelen van uw Blob Storage-toepassing.

Gereed Categorie Ontwerpoverwegingen
  Schaalbaarheidsdoelen Kunt u uw toepassing zo ontwerpen dat deze niet meer dan het maximale aantal opslagaccounts gebruikt?
  Schaalbaarheidsdoelen Wilt u niet de capaciteits- en transactielimieten benaderen?
  Schaalbaarheidsdoelen Heeft een groot aantal clients gelijktijdig toegang tot één blob?
  Schaalbaarheidsdoelen Blijft uw toepassing binnen de schaalbaarheidsdoelen voor één blob?
  Partitionering Is uw naamconventie ontworpen om een betere taakverdeling mogelijk te maken?
  Netwerken Hebben apparaten aan de clientzijde voldoende bandbreedte en lage latentie om de benodigde prestaties te verwezenlijken?
  Netwerken Hebben apparaten aan de clientzijde een netwerkkoppeling van hoge kwaliteit?
  Netwerken Bevindt de clienttoepassing zich in dezelfde regio als de opslagaccount?
  Directe clienttoegang Maakt u gebruik van Shared Access Signatures (SAS) en Cross-Origin Resource Sharing (CORS) om directe toegang tot Azure Storage te krijgen?
  Caching Worden gegevens in de toepassing in de cache opgeslagen die vaak worden geopend en zelden worden gewijzigd?
  Caching Worden er updates in batches uitgevoerd in uw toepassing door ze in de cache op de client op te slaan en ze vervolgens in grotere sets te uploaden?
  .NET-configuratie Gebruikt u .NET Core 2.1 of hoger voor optimale prestaties?
  .NET-configuratie Hebt u uw client geconfigureerd voor het gebruik van een voldoende aantal gelijktijdige verbindingen?
  .NET-configuratie Hebt u voor .NET-toepassingen .NET geconfigureerd voor het gebruik van een voldoende aantal threads?
  Parallelle uitvoering Hebt u ervoor gezorgd dat parallelle uitvoering op de juiste wijze is gebonden, zodat de functionaliteit van uw client niet wordt overbelast of de schaalbaarheidsdoelen worden genaderd?
  Hulpprogramma's Gebruikt u de nieuwste versies van door Microsoft meegeleverde clientbibliotheken en hulpprogramma's?
  Nieuwe pogingen Gebruikt u een beleid voor opnieuw proberen met exponentieel uitstel voor het beperken van fouten en time-outs?
  Nieuwe pogingen Voorkomt uw toepassing nieuwe pogingen voor fouten waarbij geen nieuwe pogingen mogelijk zijn?
  Blobs kopiëren Kopieert u blobs op de meest efficiënte manier?
  Blobs kopiëren Gebruikt u de nieuwste versie van AzCopy voor bulkkopiebewerkingen?
  Blobs kopiëren Gebruikt u de Azure Data Box-serie voor het importeren van grote hoeveelheden gegevens?
  Inhoudsdistributie Gebruikt u een CDN voor inhoudsdistributie?
  Metagegevens gebruiken Slaat u veelgebruikte metagegevens over blobs op in hun metagegevens?
  Prestaties afstemmen Stemt u de opties van de clientbibliotheek proactief af om de prestaties van gegevensoverdracht te optimaliseren?
  Snel uploaden Uploadt u blokken parallel wanneer u probeert snel één blob te uploaden?
  Snel uploaden Wanneer u veel blobs snel probeert te uploaden, uploadt u dan blobs parallel?
  Blob-type Gebruikt u pagina-blobs of blok-blobs wanneer dat nodig is?

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.

Maximumaantal opslagaccounts

Als u het maximum aantal toegestane opslagaccounts voor een bepaalde combinatie van abonnement/regio nadert, 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 schalen automatisch en zonder dat u afzonderlijke opslagaccounts hoeft te maken en te 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 verkeer, 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. Zie Grotere opslagaccounts met een hogere schaal voor meer informatie.

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 pogingen onderneemt, waarmee de beperkingen ernstiger kunnen 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 tegelijk toegang heeft 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 de netwerkomstandigheden.

Als de blob kan worden gedistribueerd via een CDN, zoals afbeeldingen of video's die vanaf een website worden geleverd, 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. De eerste is om de toegang van uw workload zodanig te sspringen dat de blob gedurende een bepaalde periode wordt geopend in plaats van dat de blob tegelijkertijd wordt geopend. U kunt de blob ook tijdelijk kopiëren naar meerdere opslagaccounts om het totale aantal 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-blob-opslagaccount te gebruiken. Een blok-blob-opslagaccount biedt een hogere aanvraagsnelheid of I/O-bewerkingen per seconde (IOPS).

U kunt ook een contentleveringsnetwerk (CDN) zoals Azure CDN gebruiken om bewerkingen op de blob te distribueren. Zie 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 sneller in één partitie verwerken dan gegevens die meerdere partities omvatten. Door uw blobs een juiste naam te geven, kunt u de efficiëntie van leesaanvragen verbeteren.

Blob Storage maakt gebruik van een partitieschema op basis van 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 blobopslag.

Partitionering op basis van een bereik betekent dat naamconventies die lexicale volgorde gebruiken (bijvoorbeeld mypayroll, myperformance, myemployees, enz.) of tijdstempels (log20160101, log20160102, log20160102, enzovoort), waarschijnlijker tot gevolg hebben dat de partities zich op dezelfde partitieserver bevinden totdat ze worden gesplitst in kleinere bereiken. Co-locatie van blobs op dezelfde partitieserver verbetert de prestaties, dus een belangrijk onderdeel van prestatieverbetering is het benoemen van blobs op een manier die ze het meest effectief organiseert.

Alle blobs in een container kunnen bijvoorbeeld worden uitgevoerd door één server totdat de belasting van deze blobs een verdere herverdeling van de partitiebereiken vereist. Op dezelfde manier kan een groep licht geladen accounts met hun namen gerangschikt in lexicale volgorde worden bediend door één server totdat de belasting op 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 gestart 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 groter dan 256 KiB voor Standard- en Premium-opslagaccounts. Grotere blob- of blokgrootten activeren automatisch blok-blobs met hoge doorvoer. Blok-blobs met hoge doorvoer bieden opname met hoge prestaties die niet worden beïnvloed door naamgeving van partities.

  • Bekijk de naamconventie die u gebruikt voor accounts, containers, blobs, tabellen en wachtrijen. Overweeg account-, container- of blobnamen voor te voegen met een hash van drie cijfers met behulp van een hash-functie die het beste bij uw behoeften past.

  • Als u uw gegevens ordent met behulp van tijdstempels of numerieke id's, moet u ervoor zorgen dat u geen alleen-toevoegend (of prepend-only) verkeerspatroon 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 dat het systeem geen effectieve taakverdeling kan uitvoeren.

    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 bediend door één partitieserver. Overweeg of de limieten per blob en per partitie voldoen aan uw behoeften en overweeg deze bewerking indien nodig op te splitsen in meerdere blobs. Als u tijdreeksgegevens opslaat in uw tabellen, 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, vervangt u het tijdstempel door de waarde voor seconden, bijvoorbeeld ssyyyymmdd. Als uw toepassing regelmatig lijst- en querybewerkingen uitvoert, kiest u een hashfunctie waarmee het aantal query's wordt beperkt. In sommige gevallen kan een willekeurig voorvoegsel voldoende zijn.

  • Zie Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency (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 Azure Storage opent vanuit een on-premises toepassing, geldt dezelfde regel: zorg ervoor dat u inzicht krijgt in de netwerkmogelijkheden van het clientapparaat en de netwerkverbinding met de Azure Storage-locatie en verbeter deze, indien nodig. U kunt ook uw toepassing zo ontwerpen dat deze binnen deze mogelijkheden kan werken.

Net als bij elk netwerkgebruik moet u er rekening mee houden dat de netwerkomstandigheden die fouten en pakketverlies veroorzaken, ervoor zorgen dat de effectieve doorvoer wordt vertraagd. 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 krijgen tot Azure Storage, maar niet worden gehost in Azure, zoals apps voor mobiele apparaten of on-premises bedrijfsservices, kan de latentie worden verminderd door het opslagaccount in een regio in de buurt van die clients te plaatsen. 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 de app opslaat specifiek zijn voor afzonderlijke gebruikers en als er geen replicatie van gegevens nodig is 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 geen JavaScript toe op een pagina die wordt gehost door een website op het ene domein om bepaalde bewerkingen, zoals schrijfbewerkingen, uit te voeren op het andere 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 de prestaties. In de volgende secties worden aanbevolen procedures voor opslaan in cache besproken.

Lezen van de gegevens

Over het algemeen is het beter om gegevens eenmaal te lezen dan twee keer te lezen. Bekijk het voorbeeld van een webtoepassing die een 50 MiB-blob heeft opgehaald uit Azure Storage om als inhoud voor een gebruiker te fungeren. Idealiter slaat de toepassing de blob lokaal in de cache op op schijf en haalt vervolgens de in de cache opgeslagen versie op voor volgende gebruikersaanvragen.

Een manier om te voorkomen dat een blob wordt opgehaald als deze niet is gewijzigd sinds deze in de cache is opgeslagen, is door de GET-bewerking te kwalificeren met een voorwaardelijke header voor wijzigingstijd. Als de laatste wijzigingstijd valt na het tijdstip waarop 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 er ook voor kiezen om uw toepassing zo te ontwerpen dat deze ervan uitgaat dat de blob gedurende een korte periode na het ophalen ongewijzigd blijft. 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 bijhoudt. De toepassing kan gegevens van elke activiteit uploaden naar een tabel (waarvoor veel opslagbewerkingen nodig zijn), of activiteitendetails opslaan in een lokaal logboekbestand en vervolgens periodiek alle activiteitsgegevens als een bestand met scheidingstekens uploaden 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 met een grootte van maximaal 64 MiB. De ontwikkelaar van de toepassing moet ontwerpen voor de mogelijkheid van clientapparaat- of uploadfouten. Als de activiteitsgegevens gedurende een tijdsinterval moeten worden gedownload in plaats van voor één activiteit, wordt het gebruik van Blob-opslag aanbevolen in plaats van Table Storage.

.NET-configuratie

Als u het .NET Framework gebruikt, worden in deze sectie verschillende snelle configuratie-instellingen weergegeven die u kunt gebruiken om belangrijke verbeteringen in de prestaties aan te brengen. Als u andere talen gebruikt, controleert u of er soortgelijke concepten van toepassing zijn in de taal die u hebt gekozen.

.NET Core gebruiken

Ontwikkel uw Azure Storage-toepassingen met .NET Core 2.1 of hoger om te profiteren van de betere prestaties. Het gebruik van .NET Core 3.x wordt aanbevolen als dat mogelijk is.

Raadpleeg de volgende blogberichten voor meer informatie over betere prestaties in .NET Core:

De standaardverbindingslimiet verhogen

In .NET verhoogt de volgende code de standaardverbindingslimiet (meestal twee in een clientomgeving of tien in een serveromgeving) naar 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)  

Voor andere programmeertalen raadpleegt u de documentatie om te bepalen hoe u de verbindingslimiet instelt.

Zie voor meer informatie het blogbericht Webservices: Gelijktijdige verbindingen.

Minimumaantal threads verhogen

Als u synchrone aanroepen gebruikt in combinatie met asynchrone taken, kunt u misschien beter 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

Parallelle uitvoering kan ideaal zijn voor de prestaties, maar wees voorzichtig met het gebruik van een ongebonden parallelle uitvoering, wat betekent dat er geen limiet wordt 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 verhelpen. Microsoft raadt aan het ABFS-stuurprogramma te gebruiken in plaats van het WASB-stuurprogramma, omdat het ABFS-stuurprogramma specifiek is geoptimaliseerd voor big data-analyse.

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.

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 echter uw toepassing beperkt omdat deze de schaalbaarheidsdoelen overschrijdt of als de service om een andere reden zelfs niet aan de aanvraag kan voldoen, kunnen agressieve nieuwe pogingen het probleem erger maken. 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.

Bij connectiviteitsfouten kunnen onmiddellijk nieuwe pogingen worden gedaan, omdat ze niet het gevolg zijn van een beperking en naar verwachting tijdelijk zijn.

Fouten waarbij geen nieuwe pogingen mogelijk zijn

Bij de clientbibliotheken is bij het afhandelen van nieuwe pogingen bekend bij welke fouten opnieuw kan worden geprobeerd en welke niet. Als u echter de Azure Storage REST API rechtstreeks aanroept, zijn er enkele fouten waarbij u geen nieuwe pogingen moet ondernemen. Bijvoorbeeld, de fout 400 (ongeldige aanvraag) geeft aan dat de clienttoepassing een aanvraag heeft verzonden die niet kan worden verwerkt omdat deze niet in de verwachte vorm is opgemaakt. Als deze aanvraag opnieuw wordt verzonden, resulteert dit steeds in hetzelfde antwoord, zodat het zinloos is om een nieuwe poging te ondernemen. Als u de REST API Azure Storage rechtstreeks aanroept, moet u rekening houden met mogelijke fouten en of er nieuwe pogingen moeten worden gedaan.

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 invloed op de prestaties. Zie Een Azure-oplossing voor gegevensoverdracht kiezen voor informatie over het efficiënt overdragen van gegevens naar of van Blob Storage.

API's voor kopiëren van blobs

Als u blobs tussen opslagaccounts wilt kopiëren, gebruikt u de bewerking Put Block From URL . Met deze bewerking worden gegevens synchroon gekopieerd van een URL-bron naar een blok-blob. Het gebruik van de bewerking kan de Put Block from URL vereiste bandbreedte aanzienlijk verminderen wanneer u gegevens migreert tussen opslagaccounts. Omdat de kopieerbewerking plaatsvindt aan de servicezijde, hoeft u de gegevens niet te downloaden en opnieuw te uploaden.

Als u gegevens binnen hetzelfde opslagaccount wilt kopiëren, gebruikt u de bewerking Blob kopiëren . Het kopiëren van gegevens binnen hetzelfde opslagaccount is doorgaans snel voltooid.

AzCopy gebruiken

Het AzCopy-opdrachtregelprogramma 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 de Azure Data Box-serie gebruiken voor offlineoverdrachten. Door Microsoft geleverde Data Box-apparaten zijn een goede keuze voor het verplaatsen van grote hoeveelheden gegevens naar Azure wanneer u wordt beperkt door tijd, netwerkbeschikbaarheid of kosten. Zie de Documentatie voor Azure DataBox voor meer informatie.

Inhoudsdistributie

Soms moet een toepassing dezelfde inhoud aanbieden aan veel gebruikers (bijvoorbeeld een productdemovideo die wordt gebruikt op de startpagina van een website), die zich in dezelfde regio of in meerdere regio's bevindt. In dit scenario gebruikt u een Content Delivery Network (CDN) zoals Azure CDN om blob-inhoud geografisch te distribueren. In tegenstelling tot een Azure Storage-account dat bestaat in één regio en dat geen inhoud met lage latentie kan leveren aan andere regio's, gebruikt Azure CDN servers in meerdere datacenters over de hele wereld. Bovendien kan een CDN doorgaans veel hogere uitgaande limieten ondersteunen dan één opslagaccount.

Zie Azure CDN voor meer informatie over Azure CDN.

Metagegevens gebruiken

De Blob-service ondersteunt HEAD-aanvragen, die blobeigenschappen of metagegevens kunnen bevatten. Als uw toepassing bijvoorbeeld de Exif-gegevens (inwisselbare afbeeldingsindeling) van een foto nodig heeft, kan de foto worden opgehaald en geëxtraheerd. 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 verkort de verwerkingstijd die nodig is om de Exif-gegevens te extraheren. Houd er rekening mee dat er per blob 8 KiB aan metagegevens kan worden opgeslagen.

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 de snelheid, het geheugengebruik en zelfs op 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 overdrachtsopties voor clientbibliotheek 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 gaat uploaden. Gebruik de onderstaande richtlijnen om de juiste methode te bepalen, afhankelijk van uw scenario. Als u de Azure Storage-clientbibliotheek gebruikt voor gegevensoverdrachten, raadpleegt u Prestaties afstemmen voor gegevensoverdrachten voor verdere richtlijnen.

Snel één grote blob uploaden

Als u snel één grote blob wilt uploaden, kan een clienttoepassing de blokken of pagina's parallel uploaden, rekening houdend met de schaalbaarheidsdoelen voor afzonderlijke blobs en het opslagaccount als geheel. De Azure Storage-clientbibliotheken ondersteunen parallel uploaden. Clientbibliotheken voor andere ondersteunde talen bieden vergelijkbare opties.

Snel veel blobs uploaden

Als u snel veel blobs wilt uploaden, uploadt u blobs parallel. Parallel uploaden is sneller dan het uploaden van één blobs tegelijk met parallelle blokuploads, omdat het uploaden wordt verdeeld over meerdere partities van de opslagservice. AzCopy voert standaard parallelle uploads 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 als 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 uit blokken bestaan. Wanneer u een toevoeg-blob wijzigt, worden alleen blokken 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 Informatie over blok-blobs, toevoeg-blobs en pagina-blobs voor meer informatie.

Volgende stappen