Настройка производительности для отправки и скачивания с помощью Python

Когда приложение передает данные с помощью клиентской библиотеки служба хранилища Azure для Python, существует несколько факторов, которые могут повлиять на скорость, использование памяти и даже на успех или сбой запроса. Чтобы повысить производительность и надежность передачи данных, важно упреждать настройку параметров передачи клиентской библиотеки в зависимости от среды, в которой работает ваше приложение.

В этой статье рассматриваются некоторые рекомендации по настройке параметров передачи данных. При правильной настройке клиентская библиотека может эффективно распределять данные по нескольким запросам, что может привести к повышению скорости операций, использованию памяти и стабильности сети.

Настройка производительности для отправки

Правильная настройка параметров передачи данных является ключом к надежной производительности для отправки. Передача хранилища секционируется на несколько подтрансферов на основе значений этих аргументов. Максимальный поддерживаемый размер передачи зависит от версии операции и службы, поэтому обязательно проверьте документацию, чтобы определить ограничения. Дополнительные сведения об ограничениях размера передачи для хранилища BLOB-объектов см. в разделе "Целевые объекты масштабирования" для хранилища BLOB-объектов.

Настройка параметров передачи для отправки

Следующие аргументы можно настроить на основе потребностей приложения:

• max_single_put_size. Максимальный размер большого двоичного объекта для отправки с одним запросом. По умолчанию используется 64 МиБ.
• max_block_size. Максимальная длина передачи в байтах при отправке блочного большого двоичного объекта в блоках. По умолчанию — 4 МиБ.
• max_concurrency: максимальное количество подтрансферов, которые могут использоваться параллельно.

Примечание.

Клиентские библиотеки будут использовать значения по умолчанию для каждого параметра передачи данных, если они не указаны. Эти значения по умолчанию обычно выполняются в среде центра обработки данных, но, скорее всего, не подходят для домашних сред потребителей. Плохо настроенные параметры передачи данных могут привести к чрезмерно длительным операциям и даже времени ожидания запросов. Рекомендуется проактивно протестировать эти значения и настроить их на основе потребностей приложения и среды.

max_single_put_size

Аргументом max_single_put_size является максимальный размер большого двоичного объекта в байтах для отправки одного запроса. Если размер большого двоичного объекта меньше или равен max_single_put_size, большой двоичный объект отправляется с одним запросом Put BLOB-объекта . Если размер большого двоичного объекта больше max_single_put_sizeили размер большого двоичного объекта неизвестен, большой двоичный объект отправляется в блоки с помощью ряда вызовов put Block, за которым следует put Block List.

Важно отметить, что указанное значение max_block_size не ограничивает заданное max_single_put_sizeзначение. Аргумент max_single_put_size определяет отдельное ограничение размера для запроса на выполнение всей операции одновременно без подтрансферов. Это часто случается, что вы хотите max_single_put_size быть по крайней мере столько, сколько значения, для которого вы определяете max_block_size, если не больше. В зависимости от размера передачи данных этот подход может быть более производительным, так как передача выполняется с одним запросом и позволяет избежать затрат на несколько запросов.

Если вы не уверены, какое значение лучше всего подходит для вашей ситуации, безопасный параметр — задать max_single_put_size то же значение, которое используется для max_block_size.

max_block_size

Аргументом max_block_size является максимальная длина передачи в байтах при отправке блочного большого двоичного объекта в блоках. Как упоминалось ранее, это значение не ограничиваетсяmax_single_put_size, что может быть большеmax_block_size.

Для эффективного перемещения данных клиентские библиотеки могут не всегда достигать значения для каждой max_block_size передачи. В зависимости от операции максимальный поддерживаемый размер передачи может отличаться. Дополнительные сведения об ограничениях размера передачи для хранилища BLOB-объектов см. на диаграмме в целевых объектах масштабирования для хранилища BLOB-объектов.

Пример кода

В следующем примере кода показано, как указать параметры передачи данных при создании BlobClient объекта и как передать данные с помощью этого клиентского объекта. Значения, указанные в этом примере, не предназначены для рекомендации. Чтобы правильно настроить эти значения, необходимо учитывать конкретные потребности приложения.

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)

В этом примере мы задали число параллельных рабочих ролей передачи 2, используя max_concurrency аргумент в вызове метода. Эта конфигурация открывает до двух подключений одновременно, что позволяет выполнять отправку параллельно. Во время создания экземпляра клиента для аргумента задано max_single_put_size значение 8 MiB. Если размер большого двоичного объекта меньше 8 МиБ, для завершения операции отправки требуется только один запрос. Если размер большого двоичного объекта превышает 8 МиБ, большой двоичный объект отправляется в блоки с максимальным размером 4 МиБ, как указано в аргументе max_block_size .

Рекомендации по производительности отправки

Во время отправки клиентские библиотеки хранилища разделяют заданный поток отправки на несколько подзагрузок на основе параметров конфигурации, определенных во время построения клиента. Каждая подзагрузка имеет собственный выделенный вызов операции REST. BlobClient Для объекта эта операция называется Put Block. Клиентская библиотека хранилища управляет этими операциями REST параллельно (в зависимости от параметров передачи) для завершения полной отправки.

Вы можете узнать, как клиентская библиотека обрабатывает буферизацию в следующих разделах.

Примечание.

Блочные большие двоичные объекты имеют максимальное количество блоков в 50 000 блоков. Максимальный размер большого двоичного объекта блока составляет 50 000 раз max_block_size.

Буферизация во время отправки

Уровень REST хранилища не поддерживает получение операции отправки REST, в которой вы оставили его. отдельные передачи либо завершены, либо потеряны. Чтобы обеспечить устойчивость потоковой передачи, клиентские библиотеки хранилища буферные данные для каждого отдельного вызова REST перед началом отправки. Помимо ограничений скорости сети, это поведение буферизации является причиной для рассмотрения меньшего значения max_block_size, даже при передаче в последовательности. Уменьшение значения max_block_size уменьшает максимальный объем данных, буферизуемых по каждому запросу, и каждое повторение неудачного запроса. Если во время передачи данных определенного размера возникают частые тайм-ауты, снижение значения max_block_size уменьшает время буферизации и может привести к повышению производительности.

По умолчанию пакет SDK буферизирует данные байтов max_block_size на одновременный запрос подзагрузки, но использование памяти может быть ограничено 4 МиБ на запрос, если выполняются следующие условия:

• Аргумент max_block_size должен быть больше min_large_block_upload_threshold. Аргумент min_large_block_upload_threshold можно определить во время создания экземпляра клиента и является минимальным размером блока в байтах, необходимым для использования эффективного алгоритма памяти. Аргумент min_large_block_upload_threshold по 4*1024*1024 + 1умолчанию.
• Предоставленный поток должен быть искать. Запрашиваемый поток — это поток, поддерживающий запросы и изменение текущей позиции в потоке.
• Большой двоичный объект должен быть блочного BLOB-объекта.

Хотя эта стратегия применяется к большинству ситуаций, при использовании других функций клиентской библиотеки, которые требуют буферизации, по-прежнему возможно больше буферизации.

Настройка производительности для загрузки

Правильная настройка параметров передачи данных является ключом к надежной производительности для загрузки. Передача хранилища секционируется на несколько подтрансферов на основе значений этих аргументов.

Настройка параметров передачи для скачивания

Следующие аргументы можно настроить на основе потребностей приложения:

• max_chunk_get_size: максимальный размер блока, используемый для скачивания большого двоичного объекта. По умолчанию — 4 МиБ.
• max_concurrency: максимальное количество подтрансферов, которые могут использоваться параллельно.
• max_single_get_size: максимальный размер большого двоичного объекта для скачивания в одном вызове. Если общий размер большого двоичного объекта превышается max_single_get_size, остальные данные большого двоичного объекта скачиваются в блоках. По умолчанию — 32 МиБ.

Пример кода

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())

Рекомендации по повышению производительности для загрузки

Во время скачивания клиентские библиотеки хранилища разделяют заданный запрос загрузки на несколько подзагрузок на основе параметров конфигурации, определенных во время построения клиента. Каждая подзагрузка имеет собственный выделенный вызов операции REST. В зависимости от параметров передачи клиентские библиотеки управляют этими операциями REST параллельно, чтобы завершить полную загрузку.

max_single_get_size для скачивания

Во время скачивания клиентские библиотеки хранилища выполняют один запрос диапазона загрузки, используя max_single_get_size его перед выполнением других действий. Во время этого первоначального запроса загрузки клиентские библиотеки знают общий размер ресурса. Если первоначальный запрос успешно скачал весь контент, операция завершится. В противном случае клиентские библиотеки продолжают выполнять запросы диапазона до max_chunk_get_size завершения полной загрузки.

Следующие шаги

• Эта статья является частью руководства разработчика хранилища BLOB-объектов для Python. Полный список статей руководства разработчика см. в статье о создании приложения.
• Дополнительные сведения о факторах, которые могут повлиять на производительность операций служба хранилища Azure, см. в статье "Задержка в хранилище BLOB-объектов".
• Чтобы просмотреть список рекомендаций по проектированию для оптимизации производительности приложений с помощью хранилища BLOB-объектов, см . контрольный список производительности и масштабируемости для хранилища BLOB-объектов.