Dlaczego rzadko odwiedzany obszar blobów platformy Azure jest wolny?

Question

Usługa chmurowa My Azure czyta i zapisuje obiekty typu blob przy użyciu biblioteki pamięci .Net (1.7). Bloby znajdują się w tym samym centrum danych, co usługa. W moim pierwszym pojemniku operacje są szybkie (rzędu 10ms). W moim drugim kontenerze są bardzo powolne (zwykle około 2s lub 14s, nie wiele pomiędzy). Oba przenoszą dane przy użyciu CloudBlob.DownloadToStream() do obiektu MemoryStream. Rozmiary plików są zwykle mniejsze niż 100 kB.

Teraz przyznaję, że nie ustanowiłem odpowiedniego testu, aby móc wykazać wszystkie powyższe - po prostu przechodzę przez moje pliki dziennika, więc może być pewna subtelna różnica w sposobie uzyskiwania dostępu do obiektów typu blob . Przepraszam, jeśli okaże się, że tak jest.

W każdym razie, jedyną istotną różnicą pomiędzy tymi dwoma pojemnikami wydaje się być:

• Szybko pojemnik jest często używane (dziesiątki tysięcy wniosków dziennie) i zwolnionym pojemnika całkiem nierzadko (być może 200 wnioski na dzień).
• Szybki kontener zazwyczaj przechowuje wkrótce dostarczone przedmioty. Powolny kontener często ładuje rzeczy, które mogły być przechowywane kilka dni temu.

Pytanie: Jakie czynniki wpływają na wydajność blob dla rzadko-dostępnych bąble? Co mogę zrobić, aby przyspieszyć?

(Nie wiem, w jaki sposób pamięć typu blob Azure jest zaimplementowana, ale w oparciu o powyższe zamierzam zgadnąć, że dane są zapisywane w macierzy pamięci i dostępne za pośrednictwem dynamicznie skalującego się zbioru VM, z których każda implementuje buforowanie obiektów typu blob w pamięci, a więc opóźnienie ~ 14s występuje, gdy platforma Azure wykryje potrzebę uruchomienia maszyn wirtualnych. Opóźnienie ~ 2s występuje, gdy maszyna wirtualna jest dostępna, ale musi pobrać dane z dysku fizycznego (wydaje się, że raczej powolne), a opóźnienie 10ms występuje, gdy element jest przechowywany w pamięci podręcznej w pamięci lub coś podobnego.)

Answer 1

Windows Azure Storage nie jest tak zaprojektowany, jak opisujesz (z rosnącą liczbą maszyn wirtualnych pamięci podręcznej) , więc nie byłoby wpływu na buforowanie niektórych danych i inne dane, które nie są buforowane w usłudze Azure Storage po stronie. Zobacz Windows Azure Storage Architecture Overview, aby uzyskać dobry przegląd, lub SOSP Paper - Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency, aby uzyskać głębszy wygląd.

Aby ustalić, dlaczego żądania BLOB są wolniejsze, najpierw należy ustalić, czy powolna wydajność jest po stronie serwera, czy po stronie klienta. Na szczęście usługa Azure Storage ułatwia to za pomocą narzędzia Storage Analytics (Windows Azure Storage Logging: Using Logs to Track Storage Requests) - wystarczy porównać opóźnienie między końcem a końcem czasu serwera. Podejrzewam, że zobaczysz jedną z dwóch rzeczy:

1. Niski poziom E2E i niski serwer. Oznaczałoby to, że albo żądanie jest opóźniane, wysyłane z klienta (np. Niewystarczająca liczba wątków roboczych), albo rejestracja dostarcza niepoprawne dane.
2. Wysoki E2E i niski serwer. Wskazuje to na problem po stronie klienta podczas przetwarzania żądania (niewystarczająca liczba wątków roboczych do przetworzenia odpowiedzi, powolne przetwarzanie strumienia pamięci itp.).