Lista kontrolna wydajności i skalowalności dla usługi Queue Storage
Firma Microsoft opracowała wiele sprawdzonych rozwiązań dotyczących tworzenia aplikacji o wysokiej wydajności za pomocą usługi Queue Storage. Ta lista kontrolna identyfikuje kluczowe rozwiązania, które deweloperzy mogą stosować, aby zoptymalizować wydajność. Należy pamiętać o tych praktykach podczas projektowania aplikacji i całego procesu.
Usługa Azure Storage ma cele dotyczące skalowalności i wydajności dla pojemności, szybkości transakcji i przepustowości. Aby uzyskać więcej informacji na temat celów skalowalności usługi Azure Storage, zobacz Cele skalowalności i wydajności dla kont magazynu w warstwie Standardowa oraz Cele skalowalności i wydajności dla usługi Queue Storage.
Lista kontrolna
Ten artykuł organizuje sprawdzone rozwiązania dotyczące wydajności na liście kontrolnej, którą można wykonać podczas tworzenia aplikacji usługi Queue Storage.
Cele skalowalności
Jeśli aplikacja zbliża się lub przekracza jakiekolwiek cele skalowalności, może wystąpić zwiększone opóźnienia transakcji lub ograniczanie przepustowości. Gdy usługa Azure Storage ogranicza aplikację, usługa zaczyna zwracać kody błędów 503 (Server Busy) lub 500 (Operation Timeout). Unikanie tych błędów, pozostając w granicach celów skalowalności, jest ważną częścią zwiększania wydajności aplikacji.
Aby uzyskać więcej informacji na temat celów skalowalności usługi Queue Storage, zobacz Cele skalowalności i wydajności usługi Azure Storage.
Maksymalna liczba kont magazynu
Jeśli zbliżasz się do maksymalnej liczby kont magazynu dozwolonych dla określonej kombinacji subskrypcji/regionu, czy używasz wielu kont magazynu do fragmentowania w celu zwiększenia liczby operacji ruchu przychodzącego, ruchu wychodzącego, operacji we/wy na sekundę (IOPS) lub pojemności? W tym scenariuszu firma Microsoft zaleca korzystanie ze zwiększonych limitów dla kont magazynu w celu zmniejszenia liczby kont magazynu wymaganych do obciążenia, jeśli to możliwe. Skontaktuj się z pomocą techniczną platformy Azure, aby zażądać zwiększonych limitów dla konta magazynu.
Cele pojemności i transakcji
Jeśli aplikacja zbliża się do celów skalowalności dla pojedynczego konta magazynu, rozważ zastosowanie jednego z następujących podejść:
- Jeśli cele skalowalności kolejek nie są wystarczające dla aplikacji, użyj wielu kolejek i dystrybuuj komunikaty między nimi.
- Rozważ obciążenie, które powoduje, że aplikacja zbliża się lub przekracza cel skalowalności. Czy można zaprojektować ją inaczej, aby używać mniejszej przepustowości lub pojemności, czy mniejszej liczby transakcji?
- Jeśli aplikacja musi przekroczyć jeden z celów skalowalności, utwórz wiele kont magazynu i podziel dane aplikacji na te wiele kont magazynu. Jeśli używasz tego wzorca, pamiętaj, aby zaprojektować aplikację, aby w przyszłości dodać więcej kont magazynu na potrzeby równoważenia obciążenia. Same konta magazynu nie mają żadnych kosztów innych niż użycie pod względem przechowywanych danych, transakcji lub przesyłanych danych.
- Jeśli aplikacja zbliża się do celów przepustowości, rozważ kompresowanie danych po stronie klienta, aby zmniejszyć przepustowość wymaganą do wysłania danych do usługi Azure Storage. Kompresowanie danych może zmniejszyć przepustowość i zwiększyć wydajność sieci, ale może również mieć negatywny wpływ na wydajność. Oceń wpływ wydajności dodatkowych wymagań dotyczących przetwarzania na kompresję i dekompresję danych po stronie klienta. Należy pamiętać, że przechowywanie skompresowanych danych może utrudnić rozwiązywanie problemów, ponieważ wyświetlenie danych przy użyciu standardowych narzędzi może być trudniejsze.
- Jeśli aplikacja zbliża się do celów skalowalności, upewnij się, że używasz wykładniczego wycofywania dla ponownych prób. Najlepiej jest spróbować uniknąć osiągnięcia celów skalowalności przez zaimplementowanie zaleceń opisanych w tym artykule. Jednak użycie wycofywania wykładniczego w przypadku ponownych prób uniemożliwia aplikacji szybkie ponawianie próby, co może pogorszyć ograniczanie przepustowości. Aby uzyskać więcej informacji, zobacz sekcję Błędy przekroczenia limitu czasu i zajętości serwera.
Sieć
Ograniczenia sieci fizycznej aplikacji mogą mieć znaczący wpływ na wydajność. W poniższych sekcjach opisano niektóre ograniczenia, które mogą napotkać użytkownicy.
Możliwość sieci klienta
Przepustowość i jakość łącza sieciowego odgrywają ważne role w wydajności aplikacji, zgodnie z opisem w poniższych sekcjach.
Przepływność
W przypadku przepustowości problem często dotyczy możliwości klienta. Większe wystąpienia platformy Azure mają karty sieciowe o większej pojemności, dlatego należy rozważyć użycie większego wystąpienia lub większej liczby maszyn wirtualnych, jeśli potrzebujesz wyższych limitów sieci z pojedynczej maszyny. Jeśli uzyskujesz dostęp do usługi Azure Storage z poziomu aplikacji lokalnej, ta sama reguła ma zastosowanie: poznaj możliwości sieciowe urządzenia klienckiego i łączność sieciową z lokalizacją usługi Azure Storage, a następnie ulepsz je zgodnie z potrzebami lub zaprojektuj aplikację do pracy w ramach swoich możliwości.
Jakość łącza
Podobnie jak w przypadku dowolnego użycia sieci, należy pamiętać, że warunki sieciowe powodujące błędy i utrata pakietów spowalnia efektywną przepływność. Korzystanie z programu Wireshark lub monitora sieciowego może pomóc w diagnozowaniu tego problemu.
Lokalizacja
W dowolnym środowisku rozproszonym umieszczenie klienta w pobliżu serwera zapewnia najlepszą wydajność. Aby uzyskać dostęp do usługi Azure Storage z najniższym opóźnieniem, najlepszą lokalizacją dla klienta jest w tym samym regionie świadczenia usługi Azure. Jeśli na przykład masz aplikację internetową platformy Azure korzystającą z usługi Azure Storage, znajdź je w jednym regionie, takim jak Zachodnie stany USA lub Azja Południowo-Wschodnia. Współlokowanie zasobów zmniejsza opóźnienie i koszt, ponieważ użycie przepustowości w jednym regionie jest bezpłatne.
Jeśli aplikacje klienckie uzyskują dostęp do usługi Azure Storage, ale nie są hostowane na platformie Azure, takie jak aplikacje urządzeń przenośnych lub lokalne usługi przedsiębiorstwa, lokalizowanie konta magazynu w regionie zbliżonym do tych klientów może zmniejszyć opóźnienie. Jeśli klienci są szeroko dystrybuowani (na przykład niektórzy w Ameryka Północna i niektórzy w Europie), rozważ użycie jednego konta magazynu na region. Takie podejście jest łatwiejsze do zaimplementowania, jeśli dane przechowywane przez aplikację są specyficzne dla poszczególnych użytkowników i nie wymagają replikowania danych między kontami magazynu.
SAS i CORS
Załóżmy, że musisz autoryzować kod, taki jak JavaScript uruchomiony w przeglądarce internetowej użytkownika lub w aplikacji na telefon komórkowy, aby uzyskać dostęp do danych w usłudze Azure Storage. Jednym z podejść jest utworzenie aplikacji usługi, która działa jako serwer proxy. Urządzenie użytkownika uwierzytelnia się w usłudze, co z kolei autoryzuje dostęp do zasobów usługi Azure Storage. W ten sposób można uniknąć uwidaczniania kluczy konta magazynu na niezabezpieczonych urządzeniach. Jednak takie podejście powoduje znaczne obciążenie aplikacji usługi, ponieważ wszystkie dane przesyłane między urządzeniem użytkownika a usługą Azure Storage muszą przechodzić przez aplikację usługi.
Możesz uniknąć używania aplikacji usługi jako serwera proxy dla usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS). Przy użyciu sygnatury dostępu współdzielonego możesz umożliwić urządzeniu użytkownika wykonywanie żądań bezpośrednio w usłudze Azure Storage przy użyciu ograniczonego tokenu dostępu. Jeśli na przykład użytkownik chce przekazać zdjęcie do aplikacji, aplikacja usługi może wygenerować sygnaturę dostępu współdzielonego i wysłać ją na urządzenie użytkownika. Token SYGNATURy dostępu współdzielonego może udzielić uprawnień do zapisu w zasobie usługi Azure Storage przez określony interwał czasu, po upływie którego token SAS wygaśnie. Aby uzyskać więcej informacji na temat sygnatur dostępu współdzielonego, zobacz Udzielanie ograniczonego dostępu do zasobów usługi Azure Storage przy użyciu sygnatur dostępu współdzielonego (SAS).
Zazwyczaj przeglądarka internetowa nie zezwala na używanie języka JavaScript na stronie hostowanej przez witrynę internetową w jednej domenie w celu wykonywania pewnych operacji, takich jak operacje zapisu, do innej domeny. Znane jako zasady tego samego źródła, te zasady uniemożliwiają złośliwemu skryptowi na jednej stronie uzyskanie dostępu do danych na innej stronie internetowej. Jednak zasady tego samego źródła mogą być ograniczeniem podczas tworzenia rozwiązania w chmurze. Współużytkowanie zasobów między źródłami (CORS) to funkcja przeglądarki, która umożliwia domenie docelowej komunikowanie się z przeglądarką, która ufa żądaniom pochodzącym z domeny źródłowej.
Załóżmy na przykład, że aplikacja internetowa działająca na platformie Azure wysyła żądanie dotyczące zasobu do konta usługi Azure Storage. Aplikacja internetowa jest domeną źródłową, a konto magazynu jest domeną docelową. Mechanizm CORS można skonfigurować dla dowolnej usługi Azure Storage, aby komunikować się z przeglądarką internetową, która żądań z domeny źródłowej jest zaufana przez usługę Azure Storage. Aby uzyskać więcej informacji na temat mechanizmu CORS, zobacz Obsługa współużytkowania zasobów między źródłami (CORS) dla usługi Azure Storage.
Sygnatura dostępu współdzielonego i mechanizm CORS mogą pomóc uniknąć niepotrzebnego ładowania aplikacji internetowej.
Konfiguracja platformy .NET
W przypadku projektów korzystających z programu .NET Framework w tej sekcji wymieniono niektóre szybkie ustawienia konfiguracji, których można użyć do wprowadzania znaczących ulepszeń wydajności. Jeśli używasz języka innego niż .NET, sprawdź, czy podobne pojęcia mają zastosowanie w wybranym języku.
Zwiększanie domyślnego limitu połączeń
Uwaga
Ta sekcja dotyczy projektów korzystających z programu .NET Framework, ponieważ buforowanie połączeń jest kontrolowane przez klasę ServicePointManager. Platforma .NET Core wprowadziła znaczącą zmianę w zarządzaniu pulą połączeń, w której buforowanie połączeń odbywa się na poziomie httpClient, a rozmiar puli nie jest domyślnie ograniczony. Oznacza to, że połączenia HTTP są automatycznie skalowane w celu zaspokojenia obciążenia. Korzystanie z najnowszej wersji platformy .NET jest zalecane, jeśli to możliwe, aby skorzystać z ulepszeń wydajności.
W przypadku projektów korzystających z programu .NET Framework można użyć następującego kodu, aby zwiększyć domyślny limit połączeń (zazwyczaj 2 w środowisku klienta lub 10 w środowisku serwera) do 100. Zazwyczaj należy ustawić wartość na około liczbę wątków używanych przez aplikację. Ustaw limit połączenia przed otwarciem jakichkolwiek połączeń.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Aby dowiedzieć się więcej na temat limitów puli połączeń w programie .NET Framework, zobacz .NET Framework Połączenie ion Pool Limits and the new Azure SDK for .NET (Limity puli Połączenie ion platformy .NET) i nowy zestaw Azure SDK dla platformy .NET.
Aby zapoznać się z innymi językami programowania, zobacz dokumentację, aby określić sposób ustawiania limitu połączeń.
Zwiększ minimalną liczbę wątków
Jeśli używasz wywołań synchronicznych wraz z zadaniami asynchronicznymi, możesz zwiększyć liczbę wątków w puli wątków:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Aby uzyskać więcej informacji, zobacz metodę ThreadPool.SetMinThreads .
Równoległość bez ruchu przychodzącego
Chociaż równoległość może być doskonała dla wydajności, należy zachować ostrożność przy użyciu niezwiązanego równoległości, co oznacza, że nie ma limitu wymuszanego dla liczby wątków lub żądań równoległych. Pamiętaj, aby ograniczyć równoległe żądania przekazywania lub pobierania danych, aby uzyskać dostęp do wielu partycji na tym samym koncie magazynu lub uzyskać dostęp do wielu elementów w tej samej partycji. Jeśli równoległość jest niezwiązana, aplikacja może przekroczyć możliwości urządzenia klienckiego lub cele skalowalności konta magazynu, co powoduje dłuższe opóźnienia i ograniczanie przepustowości.
Biblioteki i narzędzia klienckie
Aby uzyskać najlepszą wydajność, zawsze używaj najnowszych bibliotek klienckich i narzędzi udostępnianych przez firmę Microsoft. Biblioteki klienta usługi Azure Storage są dostępne dla różnych języków. Usługa Azure Storage obsługuje również program PowerShell i interfejs wiersza polecenia platformy Azure. Firma Microsoft aktywnie opracowuje te biblioteki i narzędzia klienckie z myślą o wydajności, utrzymuje je na bieżąco z najnowszymi wersjami usług i zapewnia, że obsługują one wiele sprawdzonych praktyk wydajności wewnętrznie. Aby uzyskać więcej informacji, zobacz dokumentację referencyjną usługi Azure Storage.
Obsługa błędów usługi
Usługa Azure Storage zwraca błąd, gdy usługa nie może przetworzyć żądania. Zrozumienie błędów, które mogą być zwracane przez usługę Azure Storage w danym scenariuszu, jest pomocne w optymalizacji wydajności.
Przekroczenie limitu czasu i błędy zajętości serwera
Usługa Azure Storage może ograniczyć przepustowość aplikacji, jeśli zbliża się do limitów skalowalności. W niektórych przypadkach usługa Azure Storage może nie być w stanie obsłużyć żądania z powodu niektórych przejściowych warunków. W obu przypadkach usługa może zwrócić błąd 503 (Server Busy) lub 500 (Timeout). Te błędy mogą również wystąpić, jeśli usługa ponownie równoważy partycje danych, aby zapewnić większą przepływność. Aplikacja kliencka powinna zwykle ponowić próbę wykonania operacji, która powoduje jeden z tych błędów. Jeśli jednak usługa Azure Storage ogranicza aplikację, ponieważ przekracza cele skalowalności, a nawet jeśli usługa nie mogła obsłużyć żądania z jakiegoś innego powodu, agresywne ponawianie prób może pogorszyć problem. Zaleca się używanie zasad ponawiania wykładniczego, a biblioteki klienckie są domyślne dla tego zachowania. Na przykład aplikacja może ponowić próbę po 2 sekundach, a następnie 4 sekundy, a następnie 10 sekund, a następnie 30 sekund, a następnie całkowicie zrezygnować. W ten sposób aplikacja znacznie zmniejsza obciążenie usługi, a nie zaostrza zachowanie, które może prowadzić do ograniczenia przepustowości.
błędy Połączenie wydajności można natychmiast ponowić, ponieważ nie są one wynikiem ograniczania przepustowości i powinny być przejściowe.
Błędy nienależące do ponawiania prób
Biblioteki klienckie obsługują ponawianie prób z świadomością, które błędy można ponowić i których nie można. Jeśli jednak bezpośrednio wywołujesz interfejs API REST usługi Azure Storage, występują pewne błędy, których nie należy ponawiać. Na przykład błąd 400 (Bad Request) wskazuje, że aplikacja kliencka wysłała żądanie, którego nie można przetworzyć, ponieważ nie było w oczekiwanym formularzu. Ponowne wysyłanie tego żądania powoduje wykonanie tej samej odpowiedzi za każdym razem, więc nie ma sensu ponawiania próby. Jeśli bezpośrednio wywołujesz interfejs API REST usługi Azure Storage, pamiętaj o potencjalnych błędach i o tym, czy należy je ponowić.
Aby uzyskać więcej informacji na temat kodów błędów usługi Azure Storage, zobacz Kody stanu i błędów.
Wyłącz algorytm Nagle
Algorytm Nagle jest szeroko implementowany w sieciach TCP/IP jako środek zwiększający wydajność sieci. Jednak nie jest to optymalne we wszystkich okolicznościach (takich jak środowiska wysoce interakcyjne). Algorytm Nagle ma negatywny wpływ na wydajność żądań do usługi Azure Table Storage i należy go wyłączyć, jeśli to możliwe.
Rozmiar komunikatu
Wydajność kolejki i skalowalność zmniejszają się wraz ze wzrostem rozmiaru komunikatów. Umieść tylko informacje potrzebne odbiornikowi w komunikacie.
Pobieranie wsadowe
W ramach jednej operacji można pobrać maksymalnie 32 komunikaty z kolejki. Pobieranie wsadowe może zmniejszyć liczbę rund z aplikacji klienckiej, co jest szczególnie przydatne w środowiskach, takich jak urządzenia przenośne, z dużym opóźnieniem.
Interwał sondowania kolejki
Większość aplikacji sonduje komunikaty z kolejki, co może być jednym z największych źródeł transakcji dla tej aplikacji. Rozważnie wybierz interwał sondowania: sondowanie zbyt często może spowodować, że aplikacja zbliży się do celów skalowalności dla kolejki. Jednak przy 200.000 transakcji za 0,01 USD (w momencie pisania), pojedynczy procesor sondowania raz na sekundę przez miesiąc będzie kosztować mniej niż 15 centów, więc koszt nie jest zwykle czynnikiem, który wpływa na wybór interwału sondowania.
Aby uzyskać aktualne informacje o kosztach, zobacz Cennik usługi Azure Storage.
Wykonywanie operacji aktualizacji komunikatu
Możesz wykonać operację aktualizacji komunikatu, aby zwiększyć limit czasu widoczności lub zaktualizować informacje o stanie komunikatu. Takie podejście może być bardziej wydajne niż przepływ pracy, który przekazuje zadanie z jednej kolejki do następnej, gdy każdy krok zadania zostanie ukończony. Aplikacja może zapisać stan zadania w komunikacie, a następnie kontynuować pracę, zamiast ponownie kolejkować komunikat dla następnego kroku zadania za każdym razem, gdy krok zostanie ukończony. Należy pamiętać, że każda operacja komunikatu aktualizacji jest liczone do celu skalowalności.
Architektura aplikacji
Użyj kolejek, aby zapewnić skalowalność architektury aplikacji. Poniżej wymieniono kilka sposobów użycia kolejek w celu zwiększenia skalowalności aplikacji:
- Za pomocą kolejek można tworzyć listy prac na potrzeby przetwarzania i wygładzania obciążeń w aplikacji. Można na przykład umieścić w kolejce żądania od użytkowników, aby wykonać pracę intensywnie korzystającą z procesora, taką jak zmiana rozmiaru przekazanych obrazów.
- Kolejki można użyć do oddzielenia części aplikacji, aby można je było skalować niezależnie. Na przykład fronton internetowy może umieścić wyniki ankiety od użytkowników do kolejki w celu późniejszej analizy i magazynu. Aby przetwarzać dane kolejki zgodnie z potrzebami, można dodać więcej wystąpień roli procesu roboczego.