Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Microsoft heeft veel bewezen procedures ontwikkeld voor het ontwikkelen van hoogwaardige toepassingen met Queue 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 Queue Storage voor meer informatie over schaalbaarheidsdoelen voor Azure Storage.
Controlelijst
In dit artikel vindt u bewezen procedures voor prestaties in een controlelijst die u kunt volgen tijdens het ontwikkelen van uw Queue Storage-toepassing.
Schaalbaarheidsdoelen
Als uw toepassing een van de schaalbaarheidsdoelen nadert of overschrijdt, kunnen er meer latenties of beperkingen optreden voor transacties. Wanneer Azure Storage uw toepassing beperkt, begint de service 503 (Server Busy
) of 500 (Operation Timeout
) foutcodes te retourneren. 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 Azure Storage-schaalbaarheids- en prestatiedoelen voor meer informatie over schaalbaarheidsdoelen voor Queue Storage.
Maximum aantal opslagaccounts
Als u het maximum aantal opslagaccounts nadert dat is toegestaan voor een bepaalde combinatie van abonnementen/regio's, 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 de schaalbaarheidsdoelen voor wachtrijen onvoldoende zijn voor uw toepassing, gebruikt u meerdere wachtrijen en distribueert u er berichten over.
- 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 het comprimeren van gegevens bandbreedte kan besparen en de netwerkprestaties kan verbeteren, kan dit ook negatieve gevolgen hebben voor de prestaties. 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 opslaan van gecomprimeerde gegevens het lastiger kan maken om problemen op te lossen, omdat het lastiger kan zijn om de gegevens weer te geven 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 Timeout- en Server Bezet-fouten voor meer informatie.
Netwerken
De beperkingen van het fysieke netwerk van de toepassing kunnen een aanzienlijke 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, is dezelfde regel van toepassing: begrijp 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 Network Monitor kan helpen bij het diagnosticeren 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, zoekt u deze beide in één regio, zoals VS - 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.
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 aan de browser kan communiceren dat het aanvragen uit het brondomein vertrouwt.
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 de webbrowser te informeren dat verzoeken vanuit het brondomein door Azure Storage worden vertrouwd. 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.
.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
Opmerking
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 2 in een clientomgeving of 10 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.
Verhoog het minimum aantal threads
Als u synchrone aanroepen samen met asynchrone taken gebruikt, kunt u het aantal threads in de threadgroep 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 hulpmiddelen
Gebruik altijd de nieuwste clientbibliotheken en hulpprogramma's van Microsoft voor de beste prestaties. Azure Storage-clientbibliotheken zijn beschikbaar voor verschillende 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. Zie de referentiedocumentatie voor Azure Storage voor meer informatie.
Servicefouten afhandelen
Azure Storage retourneert een fout wanneer de service een aanvraag niet kan verwerken. Inzicht in de fouten die in een bepaald scenario door Azure Storage kunnen worden geretourneerd, is handig voor het optimaliseren van de prestaties.
Time-out- en server-bezetfouten
Azure Storage kan uw toepassing beperken als deze de schaalbaarheidslimieten nadert. In sommige gevallen kan Azure Storage een aanvraag mogelijk niet verwerken vanwege een tijdelijke voorwaarde. In beide gevallen kan de service een fout 503 (Server Busy
) of 500 (Timeout
) 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 het opnieuw proberen met exponentiële back-off wordt aanbevolen, en de clientbibliotheken zijn standaard ingesteld op dit gedrag. Uw toepassing kan het bijvoorbeeld na 2 seconden opnieuw proberen, dan 4 seconden, vervolgens 10 seconden, dan 30 seconden en vervolgens volledig opgeven. Op deze manier vermindert uw toepassing de belasting van de service aanzienlijk, in plaats van gedrag te bevorderen dat kan leiden tot overbelasting.
Connectiviteitsfouten kunnen onmiddellijk worden herhaald, omdat ze niet het gevolg zijn van vertraging en naar verwachting van voorbijgaande aard zijn.
Fouten waarbij geen nieuwe pogingen mogelijk zijn
De clientbibliotheken verwerken nieuwe pogingen met een inzicht in welke fouten opnieuw kunnen worden geprobeerd en wat niet mogelijk is. Als u de Azure Storage REST API echter rechtstreeks aanroept, zijn er enkele fouten die u niet opnieuw moet proberen. Een 400(Bad Request
)-fout 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.
Het algoritme van Nagle uitschakelen
Het algoritme van Nagle wordt veel geïmplementeerd in TCP/IP-netwerken als een middel om de netwerkprestaties te verbeteren. Het is echter niet optimaal in alle omstandigheden (zoals zeer interactieve omgevingen). Het algoritme van Nagle heeft een negatieve invloed op de prestaties van aanvragen voor Azure Table Storage. U moet dit indien mogelijk uitschakelen.
Berichtgrootte
De prestaties en schaalbaarheid van de wachtrij nemen af naarmate de berichtgrootte toeneemt. Plaats alleen de informatie die de ontvanger nodig heeft in een bericht.
Bulksgewijs ophalen
U kunt maximaal 32 berichten uit een wachtrij ophalen in één bewerking. Batch-ophalen kan het aantal verzoeken van de clienttoepassing verminderen, wat vooral nuttig is bij omgevingen zoals mobiele apparaten die een hoge latentie hebben.
Polling-interval voor wachtrij
De meeste toepassingen peilen berichten uit een wachtrij, die een van de grootste bronnen van transacties voor die toepassing kunnen zijn. Selecteer uw polling-interval verstandig: polling kan ertoe leiden dat uw toepassing de schaalbaarheidsdoelen voor de wachtrij benadert. Bij 200.000 transacties voor $ 0,01 (op het moment van schrijven) kost één processor polling echter één keer per seconde voor een maand minder dan 15 cent, dus kosten is meestal geen factor die van invloed is op uw keuze voor polling-interval.
Zie Azure Storage-prijzen voor up-to- datumkostinformatie.
Een updateberichtbewerking uitvoeren
U kunt een updateberichtbewerking uitvoeren om de time-out voor onzichtbaarheid te verhogen of om de statusinformatie van een bericht bij te werken. Deze benadering kan efficiënter zijn dan het hebben van een werkstroom die een taak van de ene wachtrij naar de volgende doorgeeft, omdat elke stap van de taak is voltooid. Uw toepassing kan de taakstatus opslaan in het bericht en vervolgens verder werken, in plaats van het bericht opnieuw te plaatsen voor de volgende stap van de taak wanneer een stap is voltooid. Houd er rekening mee dat elke updateberichtbewerking telt voor het schaalbaarheidsdoel.
Toepassingsarchitectuur
Gebruik wachtrijen om uw toepassingsarchitectuur schaalbaar te maken. Hieronder vindt u een aantal manieren waarop u wachtrijen kunt gebruiken om uw toepassing schaalbaarder te maken:
- U kunt wachtrijen gebruiken om werkopdrachten te verzamelen voor verwerking en om werkbelastingen in uw toepassing te stroomlijnen. U kunt bijvoorbeeld aanvragen van gebruikers in de wachtrij plaatsen om processorintensief werk uit te voeren, zoals het wijzigen van het formaat van geüploade afbeeldingen.
- U kunt wachtrijen gebruiken om onderdelen van uw toepassing los te koppelen, zodat u ze onafhankelijk kunt schalen. Een webfront-end kan bijvoorbeeld enquêteresultaten van gebruikers in een wachtrij plaatsen voor latere analyse en opslag. U kunt meer exemplaren van werkrollen toevoegen om de wachtrijgegevens naar behoefte te verwerken.