Opóźnienia w magazynie obiektów blob
Opóźnienie, czasami przywoływało się jako czas odpowiedzi, to czas oczekiwania aplikacji na ukończenie żądania. Opóźnienie może mieć bezpośredni wpływ na wydajność aplikacji. Małe opóźnienie jest często ważne w scenariuszach z ludźmi w pętli, takich jak przeprowadzanie transakcji kartą kredytową lub ładowanie stron internetowych. Systemy, które muszą przetwarzać zdarzenia przychodzące z dużą szybkością, takie jak rejestrowanie telemetrii lub zdarzenia IoT, również wymagają małych opóźnień. W tym artykule opisano, jak interpretować i mierzyć opóźnienia operacji na blokowych obiektach blob oraz jak projektować aplikacje pod kątem małych opóźnień.
Usługa Azure Storage oferuje dwie różne opcje wydajności blokowych obiektów blob: Premium i Standard. Blokowe obiekty blob w warstwie Premium oferują znacznie mniejsze i bardziej spójne opóźnienie niż standardowe blokowe obiekty blob za pośrednictwem dysków SSD o wysokiej wydajności. Aby uzyskać więcej informacji, zobacz Magazyn blokowych obiektów blob o wydajności Premium w warstwach dostępu Gorąca, Chłodna i Archiwum dla danych obiektów blob.
Informacje o opóźnieniu usługi Azure Storage
Opóźnienie usługi Azure Storage jest związane z szybkościami żądań dla operacji usługi Azure Storage. Współczynniki żądań są również nazywane operacjami wejściowymi/wyjściowymi na sekundę (IOPS).
Aby obliczyć częstotliwość żądań, najpierw określ czas potrzebny na ukończenie każdego żądania, a następnie oblicz liczbę żądań, które można przetworzyć na sekundę. Załóżmy na przykład, że ukończenie żądania trwa 50 milisekund (ms). Aplikacja używająca jednego wątku z jedną operacją odczytu lub zapisu powinna osiągnąć 20 operacji we/wy na sekundę (1 sekunda lub 1000 ms/ 50 ms na żądanie). Teoretycznie, jeśli liczba wątków jest podwojona do dwóch, aplikacja powinna mieć możliwość osiągnięcia 40 operacji we/wy na sekundę. Jeśli zaległe asynchroniczne operacje odczytu lub zapisu dla każdego wątku są dwukrotnie do dwóch, aplikacja powinna mieć możliwość osiągnięcia 80 operacji we/wy na sekundę.
W praktyce stawki żądań nie zawsze są skalowane liniowo ze względu na obciążenie w kliencie z planowania zadań, przełączania kontekstu itd. Po stronie usługi może występować zmienność opóźnienia ze względu na presję systemu usługi Azure Storage, różnice w używanym nośniku magazynu, hałas z innych obciążeń, zadania konserwacji i inne czynniki. Na koniec połączenie sieciowe między klientem a serwerem może mieć wpływ na opóźnienie usługi Azure Storage z powodu przeciążenia, przekierowania lub innych zakłóceń.
Przepustowość usługi Azure Storage, nazywana również przepływnością, jest powiązana z szybkością żądań i może być obliczana przez pomnożenie współczynnika żądań (IOPS) przez rozmiar żądania. Na przykład przy założeniu, że 160 żądań na sekundę, każde 256 KiB danych powoduje przepływność 40 960 KiB na sekundę lub 40 MiB na sekundę.
Metryki opóźnień dla blokowych obiektów blob
Usługa Azure Storage udostępnia dwie metryki opóźnień dla blokowych obiektów blob. Te metryki można wyświetlić w Azure Portal:
Opóźnienie end-to-end (E2E) mierzy interwał od momentu odebrania przez usługę Azure Storage pierwszego pakietu żądania, dopóki usługa Azure Storage nie otrzyma potwierdzenia klienta w ostatnim pakiecie odpowiedzi.
Opóźnienie serwera mierzy interwał od momentu odebrania ostatniego pakietu żądania przez usługę Azure Storage do momentu zwrócenia pierwszego pakietu odpowiedzi z usługi Azure Storage.
Na poniższej ilustracji przedstawiono średnie opóźnienie powodzenia E2E i średnie opóźnienie serwera powodzenia dla przykładowego obciążenia, które wywołuje operację Get Blob :
W normalnych warunkach istnieje niewielka różnica między opóźnieniem kompleksowego a opóźnieniem serwera, co pokazuje obraz dla przykładowego obciążenia.
Jeśli przejrzysz metryki opóźnienia kompleksowego i serwera i stwierdzisz, że opóźnienie kompleksowe jest znacznie większe niż opóźnienie serwera, zbadaj i rozwiąż problem ze źródłem dodatkowego opóźnienia.
Jeśli opóźnienie kompleksowe i opóźnienie serwera są podobne, ale wymagasz mniejszego opóźnienia, rozważ migrację do magazynu blokowych obiektów blob w warstwie Premium.
Czynniki wpływające na opóźnienie
Głównym czynnikiem wpływającym na opóźnienie jest rozmiar operacji. Ukończenie większych operacji trwa dłużej, ponieważ ilość danych przesyłanych przez sieć i przetwarzanych przez usługę Azure Storage.
Na poniższym diagramie przedstawiono całkowity czas operacji o różnych rozmiarach. W przypadku małych ilości danych interwał opóźnienia jest głównie poświęcany na obsługę żądania, a nie transferowanie danych. Interwał opóźnienia zwiększa się tylko nieznacznie w miarę wzrostu rozmiaru operacji (oznaczony jako 1 na poniższym diagramie). W miarę dalszego zwiększania rozmiaru operacji więcej czasu poświęca się na transfer danych, dzięki czemu łączny interwał opóźnienia jest podzielony między obsługę żądań i transfer danych (oznaczony na poniższym diagramie 2). W przypadku większych rozmiarów operacji interwał opóźnienia jest prawie wyłącznie poświęcany na przesyłanie danych, a obsługa żądań jest w dużej mierze nieistotna (oznaczona na poniższym diagramie 3).
Czynniki konfiguracyjne klienta, takie jak współbieżność i wątkowość, również wpływają na opóźnienie. Ogólna przepływność zależy od liczby żądań magazynu w locie w dowolnym momencie i sposobu obsługi wątków przez aplikację. Zasoby klienta, w tym procesor CPU, pamięć, magazyn lokalny i interfejsy sieciowe, mogą również mieć wpływ na opóźnienie.
Przetwarzanie żądań usługi Azure Storage wymaga zasobów procesora i pamięci klienta. Jeśli klient jest pod presją ze względu na niedostatecznie obciążoną maszynę wirtualną lub jakiś proces uciekający w systemie, istnieje mniej zasobów dostępnych do przetwarzania żądań usługi Azure Storage. Wszelkie rywalizacje lub brak zasobów klienta spowodują zwiększenie opóźnienia między dwoma metrykami bez zwiększenia opóźnienia serwera.
Równie ważne jest interfejs sieciowy i potok sieciowy między klientem a usługą Azure Storage. Sama odległość fizyczna może być istotnym czynnikiem, na przykład jeśli maszyna wirtualna klienta znajduje się w innym regionie platformy Azure lub lokalnie. Inne czynniki, takie jak przeskoki sieciowe, routing usługodawcy internetowego i stan Internetu, mogą mieć wpływ na ogólne opóźnienie magazynu.
Aby ocenić opóźnienie, najpierw ustanów metryki punktu odniesienia dla danego scenariusza. Metryki linii bazowej zapewniają oczekiwane opóźnienie end-to-end i serwera w kontekście środowiska aplikacji, w zależności od profilu obciążenia, ustawień konfiguracji aplikacji, zasobów klienta, potoku sieciowego i innych czynników. Jeśli masz metryki punktu odniesienia, możesz łatwiej identyfikować nietypowe i normalne warunki. Metryki linii bazowej umożliwiają również obserwowanie efektów zmienionych parametrów, takich jak konfiguracja aplikacji lub rozmiary maszyn wirtualnych.