Udostępnij za pośrednictwem

Dostrajanie wydajności przekazywania i pobierania za pomocą języka Python

  • Artykuł

Gdy aplikacja przesyła dane przy użyciu biblioteki klienta usługi Azure Storage dla języka Python, istnieje kilka czynników, które mogą mieć wpływ na szybkość, użycie pamięci, a nawet powodzenie lub niepowodzenie żądania. Aby zmaksymalizować wydajność i niezawodność transferów danych, ważne jest, aby aktywnie konfigurować opcje transferu biblioteki klienta w oparciu o środowisko, w których działa aplikacja.

W tym artykule przedstawiono kilka zagadnień dotyczących dostrajania opcji transferu danych. Odpowiednio dostrojona biblioteka klienta może efektywnie dystrybuować dane między wieloma żądaniami, co może spowodować zwiększenie szybkości działania, użycia pamięci i stabilności sieci.

Dostrajanie wydajności przekazywania

Prawidłowe dostrajanie opcji transferu danych jest kluczem do niezawodnej wydajności przekazywania. Transfery magazynu są podzielone na kilka podtransferów na podstawie wartości tych argumentów. Maksymalny obsługiwany rozmiar transferu różni się w zależności od wersji operacji i usługi, dlatego zapoznaj się z dokumentacją, aby określić limity. Aby uzyskać więcej informacji na temat limitów rozmiaru transferu dla usługi Blob Storage, zobacz Skalowanie obiektów docelowych dla usługi Blob Storage.

Ustawianie opcji transferu dla przekazywania

Na podstawie potrzeb aplikacji można dostroić następujące argumenty:

  • max_single_put_size: maksymalny rozmiar obiektu blob do przekazania za pomocą pojedynczego żądania. Wartość domyślna to 64 MiB.
  • max_block_size: maksymalna długość transferu w bajtach podczas przekazywania blokowego obiektu blob we fragmentach. Wartość domyślna to 4 MiB.
  • max_concurrency: maksymalna liczba podtransferów, które mogą być używane równolegle.

Uwaga

Biblioteki klienckie będą używać wartości domyślnych dla każdej opcji transferu danych, jeśli nie zostanie podana. Te wartości domyślne są zwykle wykonywane w środowisku centrum danych, ale prawdopodobnie nie będą odpowiednie dla środowisk użytkownika domowego. Źle dostrojone opcje transferu danych mogą spowodować zbyt długie operacje, a nawet przekroczenia limitu czasu żądania. Najlepiej proaktywnie testować te wartości i dostrajać je w zależności od potrzeb aplikacji i środowiska.

max_single_put_size

Argumentem max_single_put_size jest maksymalny rozmiar obiektu blob w bajtach dla przekazywania pojedynczego żądania. Jeśli rozmiar obiektu blob jest mniejszy lub równy max_single_put_size, obiekt blob jest przekazywany za pomocą pojedynczego żądania put blob . Jeśli rozmiar obiektu blob jest większy niż max_single_put_size, lub jeśli rozmiar obiektu blob jest nieznany, obiekt blob jest przekazywany we fragmentach przy użyciu serii wywołań Put Block , a następnie umieść listę bloków.

Należy pamiętać, że określona max_block_size wartość nie ogranicza wartości zdefiniowanej dla elementu max_single_put_size. Argument max_single_put_size definiuje oddzielne ograniczenie rozmiaru dla żądania do wykonania całej operacji jednocześnie bez podtransferów. Często zdarza się, że chcesz max_single_put_size być co najmniej tak duża, jak wartość zdefiniowana dla max_block_sizeparametru , jeśli nie jest większa. W zależności od rozmiaru transferu danych takie podejście może być bardziej wydajne, ponieważ transfer jest wykonywany przy użyciu jednego żądania i pozwala uniknąć narzutów na wiele żądań.

Jeśli nie masz pewności, jaka wartość jest najlepsza dla twojej sytuacji, bezpieczna opcja to ustawienie max_single_put_size tej samej wartości używanej dla elementu max_block_size.

max_block_size

Argument max_block_size jest maksymalną długością transferu w bajtach podczas przekazywania blokowego obiektu blob we fragmentach. Jak wspomniano wcześniej, ta wartość nie ogranicza max_single_put_sizewartości , która może być większa niż max_block_size.

Aby wydajnie przenosić dane, biblioteki klienckie mogą nie zawsze osiągać max_block_size wartość dla każdego transferu. W zależności od operacji maksymalna obsługiwana wartość rozmiaru transferu może się różnić. Aby uzyskać więcej informacji na temat limitów rozmiaru transferu dla usługi Blob Storage, zobacz wykres w temacie Skalowanie obiektów docelowych dla usługi Blob Storage.

Przykład kodu

Poniższy przykład kodu przedstawia sposób określania opcji transferu danych podczas tworzenia BlobClient obiektu oraz sposobu przekazywania danych przy użyciu tego obiektu klienta. Wartości podane w tym przykładzie nie są przeznaczone do zalecenia. Aby prawidłowo dostosować te wartości, należy wziąć pod uwagę konkretne potrzeby aplikacji.

def upload_blob_transfer_options(self, account_url: str, container_name: str, blob_name: str):
    # Create a BlobClient object with data transfer options for upload
    blob_client = BlobClient(
        account_url=account_url, 
        container_name=container_name, 
        blob_name=blob_name,
        credential=DefaultAzureCredential(),
        max_block_size=1024*1024*4, # 4 MiB
        max_single_put_size=1024*1024*8 # 8 MiB
    )
    
    with open(file=os.path.join(r'file_path', blob_name), mode="rb") as data:
        blob_client = blob_client.upload_blob(data=data, overwrite=True, max_concurrency=2)

W tym przykładzie ustawiliśmy liczbę równoległych procesów roboczych transferu na 2, używając argumentu max_concurrency wywołania metody. Ta konfiguracja otwiera maksymalnie dwa połączenia jednocześnie, co pozwala na równoległe przekazywanie. Podczas tworzenia wystąpienia klienta ustawiamy max_single_put_size argument na wartość 8 MiB. Jeśli rozmiar obiektu blob jest mniejszy niż 8 MiB, tylko jedno żądanie jest niezbędne do ukończenia operacji przekazywania. Jeśli rozmiar obiektu blob jest większy niż 8 MiB, obiekt blob jest przekazywany we fragmentach z maksymalnym rozmiarem fragmentu wynoszącym 4 MiB, zgodnie z ustawieniem argumentu max_block_size .

Zagadnienia dotyczące wydajności przekazywania

Podczas przekazywania biblioteki klienta usługi Storage dzielą dany strumień przekazywania na wiele podciążeń na podstawie opcji konfiguracji zdefiniowanych podczas budowy klienta. Każdy podładunek ma własne dedykowane wywołanie operacji REST. BlobClient W przypadku obiektu ta operacja to Put Block. Biblioteka klienta usługi Storage zarządza tymi operacjami REST równolegle (w zależności od opcji transferu), aby ukończyć pełne przekazywanie.

Możesz dowiedzieć się, jak biblioteka klienta obsługuje buforowanie w poniższych sekcjach.

Uwaga

Blokowe obiekty blob mają maksymalną liczbę bloków wynoszącą 50 000 bloków. Maksymalny rozmiar blokowego obiektu blob to 50 000 razy max_block_size.

Buforowanie podczas przekazywania

Warstwa REST magazynu nie obsługuje wybierania operacji przekazywania REST, w której została przerwana; indywidualne transfery są ukończone lub utracone. Aby zapewnić odporność na przekazywanie strumienia, biblioteki klienckie usługi Storage buforują dane dla każdego wywołania REST przed rozpoczęciem przekazywania. Oprócz ograniczeń szybkości sieci zachowanie buforowania jest powodem, dla którego należy wziąć pod uwagę mniejszą wartość max_block_size, nawet w przypadku przekazywania w sekwencji. Zmniejszenie wartości max_block_size zmniejsza maksymalną ilość danych buforowanych dla każdego żądania i ponawianie próby żądania, które zakończyło się niepowodzeniem. Jeśli występują częste przekroczenia limitu czasu podczas transferów danych o określonym rozmiarze, zmniejszenie wartości max_block_size skraca czas buforowania i może spowodować lepszą wydajność.

Domyślnie zestaw SDK buforuje dane bajtów max_block_size na jednoczesne żądanie podładowania, ale użycie pamięci może być ograniczone do 4 MiB na żądanie, jeśli spełnione są następujące warunki:

  • Argument max_block_size musi być większy niż min_large_block_upload_threshold. min_large_block_upload_threshold Argument można zdefiniować podczas tworzenia wystąpienia klienta i jest minimalnym rozmiarem fragmentu w bajtach wymaganych do korzystania z algorytmu wydajnego pamięci. Argument min_large_block_upload_threshold domyślnie ma wartość 4*1024*1024 + 1.
  • Podany strumień musi być wyszukiwany. Strumień z możliwością wyszukiwania to strumień, który obsługuje wykonywanie zapytań i modyfikowanie bieżącego położenia w strumieniu.
  • Obiekt blob musi być blokowym obiektem blob.

Chociaż ta strategia ma zastosowanie do większości sytuacji, nadal istnieje możliwość zwiększenia buforowania, jeśli kod korzysta z innych funkcji biblioteki klienta, które wymagają buforowania.

Dostrajanie wydajności pobierania

Prawidłowe dostrajanie opcji transferu danych jest kluczem do niezawodnej wydajności pobierania. Transfery magazynu są podzielone na kilka podtransferów na podstawie wartości tych argumentów.

Ustawianie opcji transferu dla pobierania

Na podstawie potrzeb aplikacji można dostroić następujące argumenty:

  • max_chunk_get_size: maksymalny rozmiar fragmentu używany do pobierania obiektu blob. Wartość domyślna to 4 MiB.
  • max_concurrency: maksymalna liczba podtransferów, które mogą być używane równolegle.
  • max_single_get_size: maksymalny rozmiar obiektu blob do pobrania w jednym wywołaniu. Jeśli łączny max_single_get_sizerozmiar obiektu blob przekroczy wartość , pozostałe dane obiektu blob są pobierane we fragmentach. Wartość domyślna to 32 MiB.

Przykład kodu

def download_blob_transfer_options(self, account_url: str, container_name: str, blob_name: str):
    # Create a BlobClient object with data transfer options for download
    blob_client = BlobClient(
        account_url=account_url, 
        container_name=container_name, 
        blob_name=blob_name,
        credential=DefaultAzureCredential(),
        max_single_get_size=1024*1024*32, # 32 MiB
        max_chunk_get_size=1024*1024*4 # 4 MiB
    )

    with open(file=os.path.join(r'file_path', 'file_name'), mode="wb") as sample_blob:
        download_stream = blob_client.download_blob(max_concurrency=2)
        sample_blob.write(download_stream.readall())

Zagadnienia dotyczące wydajności pobierania

Podczas pobierania biblioteki klienckie usługi Storage dzielą dane żądanie pobierania na wiele podpobierze na podstawie opcji konfiguracji zdefiniowanych podczas budowy klienta. Każde podpobierz ma własne dedykowane wywołanie operacji REST. W zależności od opcji transferu biblioteki klienckie zarządzają tymi operacjami REST równolegle w celu ukończenia pełnego pobierania.

max_single_get_size do pobrania

Podczas pobierania biblioteki klienckie usługi Storage tworzą jedno żądanie zakresu pobierania przy użyciu max_single_get_size przed wykonaniem czegokolwiek innego. Podczas tego początkowego żądania pobierania biblioteki klienckie znają całkowity rozmiar zasobu. Jeśli początkowe żądanie pomyślnie pobrało całą zawartość, operacja zostanie ukończona. W przeciwnym razie biblioteki klienckie nadal wysyłają żądania zakresu do max_chunk_get_size momentu ukończenia pełnego pobierania.

Następne kroki