Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Opóźnienie, czasami określane jako czas odpowiedzi, to czas, który aplikacja musi czekać na zakoń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 kredytowych lub ładowanie stron internetowych. Systemy, które wymagają przetwarzania zdarzeń przychodzących o wysokich szybkościach, takich jak rejestrowanie telemetrii lub zdarzenia IoT, również wymagają małego opóźnienia. W tym artykule opisano sposób interpretowania i mierzenia opóźnienia operacji na blokowych obiektach blob oraz projektowania aplikacji pod kątem małych opóźnień.
Usługa Azure Storage oferuje dwie różne opcje wydajności dla blokowych blobów: premium i standard. Bloby blokowe warstwy Premium oferują znacznie mniejsze i bardziej spójne opóźnienia niż standardowe bloby blokowe dzięki dyskom SSD o wysokiej wydajności. Aby uzyskać więcej informacji, zobacz: Konta magazynu obiektów blokowych blob Premium.
Informacje o opóźnieniu usługi Azure Storage
Opóźnienie usługi Azure Storage jest związane ze stawkami żądań dla operacji usługi Azure Storage. Współczynniki żądań są również nazywane operacjami wejścia/wyjścia na sekundę (IOPS).
Aby obliczyć częstotliwość żądań, najpierw określ czas potrzebny na ukończenie każdego żądania, a następnie oblicz, ile żądań można przetworzyć na sekundę. Załóżmy na przykład, że ukończenie żądania trwa 50 milisekund (ms). Aplikacja korzystająca z jednego wątku z jedną trwającą operacją odczytu lub zapisu powinna osiągnąć 20 operacji we/wy na sekundę (Input/Output Operations Per Second) (1 sekunda lub 1000 ms / 50 ms na żądanie). Teoretycznie, jeśli liczba wątków zostanie podwojona do dwóch, aplikacja powinna być w stanie osiągnąć 40 operacji we/wy na sekundę. Jeśli oczekujące operacje asynchronicznego odczytu lub zapisu dla każdego wątku zostaną podwojone do dwóch, aplikacja powinna być w stanie osiągnąć 80 IOPS.
W praktyce stawki żądań nie zawsze są skalowane liniowo ze względu na obciążenie klienta z planowania zadań, przełączania kontekstu itd. Po stronie usługi może występować zmienność opóźnienia ze względu na presję na system Azure Storage, różnice w używanym nośniku magazynu, zakłócenia z powodu 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 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 blobów
Usługa Azure Storage udostępnia dwie metryki opóźnienia dla blobów blokowych. Te metryki można wyświetlić w witrynie Azure Portal:
Opóźnienie end-to-end (E2E) mierzy interwał od momentu odebrania pierwszego pakietu żądania przez usługę Azure Storage, 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 E2E sukcesu i średnie opóźnienie sukcesu serwera dla przykładowego obciążenia, które wywołuje operację Get Blob.
W normalnych warunkach występuje niewielka różnica między końcowym opóźnieniem a opóźnieniem serwera, co pokazuje obraz dla przykładowego obciążenia.
Jeśli zapoznasz się z metrykami opóźnienia kompleksowego i serwera i okaże się, ż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 całkowite opóźnienie i opóźnienie serwera są podobne, ale wymagasz mniejszego opóźnienia, rozważ migrację do magazynu blokowych danych 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 z powodu ilości danych przesyłanych przez sieć i przetwarzanych przez usługę Azure Storage.
Na poniższym diagramie przedstawiono łączny 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, gdy rozmiar operacji wzrasta (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ń przechowywania w locie w dowolnym momencie oraz od sposobu, w jaki aplikacja obsługuje wątki. 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 zbyt słabą maszynę wirtualną lub jakiś niekontrolowany proces w systemie, istnieje mniej zasobów dostępnych do przetwarzania żądań Azure Storage. Wszelkie konflikty lub brak zasobów klienta spowodują zwiększenie opóźnienia całkowitego bez zwiększenia opóźnienia serwera, co zwiększa różnicę między tymi dwoma metrykami.
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 pamięci masowej.
Aby ocenić opóźnienie, najpierw ustanów metryki punktu odniesienia dla danego scenariusza. W kontekście środowiska aplikacji metryki linii bazowej zapewniają oczekiwane pełne opóźnienie i opóźnienie serwera, które zależą od profilu obciążenia, ustawień jej konfiguracji, zasobów klienta, przepustowości sieciowej 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 skutków zmienionych parametrów, takich jak konfiguracja aplikacji lub rozmiary maszyn wirtualnych.