Skalbarhets- och prestandamål för Queue Storage
Den här referensen beskriver skalbarhets- och prestandamål för Azure Storage. Skalbarhets- och prestandamålen som anges här är avancerade mål, men de kan uppnås. I samtliga fall beror begärandefrekvensen och bandbredden som uppnås av ditt lagringskonto på storleken på lagrade objekt, de åtkomstmönster som används och vilken typ av arbetsbelastning ditt program utför.
Se till att testa din tjänst för att avgöra om dess prestanda uppfyller dina krav. Undvik om möjligt plötsliga toppar i trafikhastigheten och se till att trafiken är väl fördelad mellan partitioner.
När ditt program når gränsen för vad en partition kan hantera för din arbetsbelastning börjar Azure Storage returnera felkoden 503 (servern är upptagen) eller felkoden 500 (åtgärdstimeout) svar. Om 503 fel inträffar kan du överväga att ändra programmet så att det använder en exponentiell backoff-princip för återförsök. Den exponentiella backoffen gör att belastningen på partitionen kan minska och underlätta toppar i trafiken till partitionen.
Skalningsmål för Queue Storage
| Resurs | Mål |
|---|---|
| Maximal storlek för en enskild kö | 500 TiB |
| Maximal storlek för ett meddelande i en kö | 64 KiB |
| Maximalt antal lagrade åtkomstprinciper per kö | 5 |
| Maximal begärandefrekvens per lagringskonto | 20 000 meddelanden per sekund, vilket förutsätter en meddelandestorlek på 1 KiB |
| Måldataflöde för en enskild kö (1-KiB-meddelanden) | Upp till 2 000 meddelanden per sekund |