Controlelijst voor prestaties en schaalbaarheid van Queue Storage
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 van Azure Storage.
Checklijst
In dit artikel worden bewezen procedures voor prestaties georganiseerd 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 met het retourneren van de foutcodes 503 (Server Busy) of 500 (Operation Timeout). 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 Queue Storage.
Maximum aantal opslagaccounts
Als u het maximumaantal opslagaccounts nadert dat is toegestaan voor een bepaalde combinatie van abonnement/regio, maakt u dan gebruik van meerdere opslagaccounts om in een shard op te slaan, waarmee de hoeveelheid inkomend/uitgaand verkeer, het aantal I/O-bewerkingen per seconde (IOPS) of de capaciteit wordt verhoogd? 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 niet voldoende zijn voor uw toepassing, moet u meerdere wachtrijen gebruiken en berichten over deze wachtrijen verdelen.
- 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. Raadpleeg de sectie Time-out- en server-bezetfouten 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, plaatst u deze beide binnen éé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 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.
.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 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.
Minimumaantal threads verhogen
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 hulpprogramma's
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 bij 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 opnieuw proberen met exponentieel uitstel wordt aanbevolen. 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 verergerend gedrag te vertonen dat kan leiden tot aanvraagbeperking.
Verbinding maken iviteitsfouten 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 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.
Algoritme van Nagle uitschakelen
Het Nagle-algoritme is breed geïmplementeerd in TCP/IP-netwerken 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, en moet zo mogelijk worden uitgeschakeld.
Berichtgrootte
Naarmate de berichtgrootte toeneemt, nemen de wachtrijprestaties en schaalbaarheid af. Plaats in een bericht alleen informatie die de ontvanger daadwerkelijk nodig heeft.
Bulksgewijs ophalen
U kunt in één bewerking maximaal 32 berichten in een wachtrij ophalen. Door bulksgewijs berichten op te halen, hoeft u minder vaak terug naar de clienttoepassing. Dit is met name handig voor omgevingen met een hoge latentie, zoals mobiele apparaten.
Polling-interval voor de wachtrij
Bij de meeste toepassingen wordt polling naar berichten in een wachtrij uitgevoerd. Dit kan al snel een van de grootste transactiebronnen voor die toepassingen worden. Wees verstandig bij het selecteren van uw polling-interval: door te vaak polling uit te voeren, is de kans groot dat de schaalbaarheidsdoelen voor de wachtrij worden bereikt voor uw toepassing. 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 Prijzen voor Azure Storage voor de actuele prijsgegevens.
Een bewerking voor bericht bijwerken uitvoeren
U kunt een bewerking voor bericht bijwerken gebruiken om de onzichtbaarheidstime-out te verhogen of om de statusgegevens van een bericht bij te werken. Soms is deze benadering efficiënter dan een werkstroom die een taak van de ene aan de andere wachtrij doorgeeft bij elke voltooide stap van de taak. Uw toepassing kan de taakstatus bij het bericht opslaan en vervolgens doorwerken, in plaats van steeds het bericht voor de volgende stap opnieuw in de wachtrij te plaatsen wanneer er weer een stap is voltooid. Vergeet niet dat elke bewerking voor bericht bijwerken meetelt voor het schaalbaarheidsdoel.
Toepassingsarchitectuur
Gebruik wachtrijen om de architectuur van uw toepassing schaalbaar te maken. Hieronder volgt een aantal manieren waarop u uw toepassing met behulp van wachtrijen schaalbaarder kunt maken:
- U kunt wachtrijen gebruiken om achterstanden voor verwerking te verzamelen en de workloads in uw toepassing soepeler laten verlopen. U kunt bijvoorbeeld aanvragen van gebruikers in een wachtrij plaatsen om eerst werkzaamheden uit te voeren die veel van de processor vergen, zoals het aanpassen van de grootte van geüploade afbeeldingen.
- U kunt wachtrijen gebruiken om de koppeling van onderdelen van uw toepassing te verbreken, zodat u de schaal van die onderdelen onafhankelijk kunt aanpassen. Met een webfront kunt u bijvoorbeeld enquêteresultaten van gebruikers in een wachtrij plaatsen, zodat u ze later kunt analyseren en opslaan. U kunt meer werkrolexemplaren toevoegen om de gegevens in de wachtrij naar wens te verwerken.
Volgende stappen
Feedback
Binnenkort: Gedurende 2024 worden GitHub Issues uitgefaseerd als het feedbackmechanisme voor inhoud. Dit wordt vervangen door een nieuw feedbacksysteem. Ga voor meer informatie naar: https://aka.ms/ContentUserFeedback.
Feedback verzenden en bekijken voor