Partager via

Réglage du niveau de performance pour les chargements et les téléchargements avec Python

  • Article

Lorsqu’une application transfère des données à l’aide de la bibliothèque de client Stockage Azure pour Python, plusieurs facteurs peuvent affecter la vitesse, l’utilisation de la mémoire et même la réussite ou l’échec de la demande. Pour optimiser les performances et la fiabilité des transferts de données, il est important de configurer les options de transfert d’une bibliothèque de client de manière proactive en fonction de l’environnement dans lequel l’application s’exécute.

Cet article décrit plusieurs considérations relatives au réglage des options de transfert de données. Lorsqu’elle est correctement paramétrée, la bibliothèque cliente peut distribuer efficacement les données entre plusieurs requêtes, ce qui peut améliorer la vitesse d’opération, l’utilisation de la mémoire et la stabilité du réseau.

Réglage des performances des chargements

Le réglage correct des options de transfert de données est essentiel pour des performances fiables pour les chargements. Les transferts de stockage sont divisés en plusieurs sous-transferts en fonction des valeurs de ces arguments. La taille maximale de transfert prise en charge varie selon l’opération et la version du service. Veillez donc à consulter la documentation pour déterminer les limites. Pour plus d’informations sur les limites de taille de transfert pour le stockage Blob, consultez Cibles de mise à l’échelle pour le stockage Blob.

Définir les options de transfert pour les chargements

Les arguments suivants peuvent être réglés en fonction des besoins de votre application :

  • max_single_put_size : taille maximale d’un objet blob à charger avec une seule requête. La valeur par défaut est 64 Mio.
  • max_block_size : longueur maximale d’un transfert en octets lors du chargement d’un objet blob de blocs en blocs. La valeur par défaut est 4 Mio.
  • max_concurrency : nombre maximal de sous-transferts pouvant être utilisés en parallèle.

Notes

Les bibliothèques de client utilisent les valeurs par défaut pour chaque option de transfert de données, si elles ne sont pas fournies. Ces valeurs par défaut sont généralement performantes dans un environnement de centre de données, mais elles ne sont pas susceptibles d’être adaptées aux environnements de consommation domestique. Un réglage médiocre des options de transfert de données peut entraîner des opérations excessivement longues et même des délais d’attente de demande. Il est préférable d’être proactif dans le test de ces valeurs, et de les régler en fonction des besoins de votre application et de votre environnement.

max_single_put_size

L’argument max_single_put_size est la taille maximale de l’objet blob en octets pour un chargement de requête unique. Si la taille du blob est inférieure ou égale à max_single_put_size, le blob est chargé avec une seule requête Put Blob. Si la taille de l’objet blob est supérieure à max_single_put_size ou si la taille de l’objet blob est inconnue, l’objet blob est chargé en blocs à l’aide d’une série d’appels Put Block suivie de Put Block List.

Il est important de noter que la valeur pour laquelle vous spécifiez max_block_size ne limite pas la valeur que vous définissez pour max_single_put_size. L’argument max_single_put_size définit une limitation de taille distincte pour une requête permettant d’effectuer l’ensemble de l’opération en même temps, sans sous-transfert. Il arrive souvent que vous souhaitiez que max_single_put_size soit au moins aussi importante que la valeur que vous définissez pour max_block_size, si ce n’est plus. En fonction de la taille du transfert de données, cette approche peut être plus performante, car le transfert est effectué avec une seule demande et évite la surcharge de plusieurs demandes.

Si vous n’êtes pas sûr de la valeur la mieux adaptée à votre situation, une option sécurisée consiste à définir max_single_put_size sur la même valeur que celle utilisée pour max_block_size.

max_block_size

L’argument max_block_size est la longueur maximale d’un transfert en octets lors du chargement d’un objet blob de blocs en blocs. Comme mentionné précédemment, cette valeur ne limite max_single_put_sizepas, qui peut être supérieure à max_block_size.

Pour que les données se déplacent efficacement, les bibliothèques clientes peuvent ne pas toujours atteindre la valeur max_block_size pour chaque transfert. Selon l’opération, la valeur maximale prise en charge pour la taille de transfert peut varier. Pour plus d’informations sur les limites de taille de transfert pour le stockage Blob, consultez le graphique dans Cibles de mise à l’échelle pour le stockage Blob.

Exemple de code

L’exemple de code suivant montre comment spécifier les options de transfert de données lors de la création d’un objet BlobClient, et comment charger les données à l’aide de cet objet client. Les valeurs fournies dans cet exemple ne sont pas destinées à être une recommandation. Pour régler correctement ces valeurs, vous devez tenir compte des besoins spécifiques de votre application.

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)

Dans cet exemple, nous définissons le nombre de workers de transfert parallèle sur 2, à l’aide de l’argument max_concurrency sur l’appel de méthode. Cette configuration ouvre jusqu’à deux connexions simultanément, ce qui permet au chargement de se produire en parallèle. Pendant l’instanciation du client, nous définissons l’argument max_single_put_size sur 8 Mio. Si la taille de l’objet blob est inférieure à 8 Mio, une seule requête est nécessaire pour terminer l’opération de chargement. Si la taille de l’objet blob est supérieure à 8 Mio, l’objet blob est chargé en blocs avec une taille de bloc maximale de 4 Mio, comme définie par l’argument max_block_size.

Considérations relatives aux performances pour les chargements

Pendant un chargement, les bibliothèques de client de stockage divisent un flux de chargement donné en plusieurs sous-chargements en fonction des options de configuration définies lors de la construction du client. Chaque sous-chargement a son propre appel dédié à l’opération REST. Pour un objet BlobClient, cette opération est Put Block. La bibliothèque cliente de stockage gère ces opérations REST en parallèle (en fonction des options de transfert) pour terminer le chargement complet.

Vous pouvez découvrir comment la bibliothèque de client gère la mise en mémoire tampon dans les sections suivantes.

Notes

Les objets blob de blocs ont un nombre maximal de blocs de 50 000 blocs. La taille maximale de votre objet blob de blocs est alors de 50 000 fois max_block_size.

Mise en mémoire tampon pendant les chargements

La couche REST de stockage ne prend pas en charge la prise en charge d’une opération de chargement REST là où vous l’avez laissée ; les transferts individuels sont terminés ou perdus. Pour garantir la résilience pour les chargements de flux, les bibliothèques de client de stockage mettent en mémoire tampon les données de chaque appel REST individuel avant de commencer le chargement. En plus des limitations de vitesse réseau, ce comportement de mise en mémoire tampon est une raison d’envisager une valeur plus petite pour max_block_size, même lors du chargement dans l’ordre. La diminution de la valeur de max_block_size réduit la quantité maximale de données mises en mémoire tampon sur chaque requête et chaque nouvelle tentative d’une requête ayant échoué. Si les délais d’expiration pendant les transferts de données d’une certaine taille sont fréquents, la réduction de la valeur max_block_size réduit le temps de mise en mémoire tampon et peut entraîner de meilleures performances.

Par défaut, le SDK met en mémoire tampon les données de max_block_size octets par requête de sous-chargement simultanée, mais l’utilisation de la mémoire peut être limitée à 4 Mio par demande si les conditions suivantes sont remplies :

  • L'argument max_block_size doit être supérieur à min_large_block_upload_threshold. L’argument min_large_block_upload_threshold peut être défini lors de l’instanciation du client. Il s’agit de la taille de bloc minimale en octets requise pour utiliser l’algorithme efficace en mémoire. Par défaut, l’argument min_large_block_upload_threshold a la valeur 4*1024*1024 + 1.
  • Le flux fourni doit pouvoir faire l'objet de recherches. Un flux pouvant être recherché est un flux qui prend en charge l’interrogation et la modification de la position actuelle dans un flux.
  • L’objet blob doit être un objet blob de blocs.

Bien que cette stratégie s’applique dans la plupart des situations, il est toujours possible que davantage de mise en mémoire tampon se produise si votre code utilise d’autres fonctionnalités de bibliothèque de client qui nécessitent une mise en mémoire tampon.

Réglage des performances des téléchargements

Le réglage correct des options de transfert de données est essentiel pour des performances fiables pour les téléchargements. Les transferts de stockage sont divisés en plusieurs sous-transferts en fonction des valeurs de ces arguments.

Définir les options de transfert pour les téléchargements

Les arguments suivants peuvent être réglés en fonction des besoins de votre application :

  • max_chunk_get_size : taille de bloc maximale utilisée pour le téléchargement d’un blob. La valeur par défaut est 4 Mio.
  • max_concurrency : nombre maximal de sous-transferts pouvant être utilisés en parallèle.
  • max_single_get_size : taille maximale pour un blob à télécharger en un seul appel. Si la taille totale du blob dépasse max_single_get_size, le reste des données blob est téléchargé en blocs. La valeur par défaut est 32 Mio.

Exemple de code

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

Considérations relatives aux performances pour les téléchargements

Pendant un téléchargement, les bibliothèques de client de stockage fractionnent une requête de téléchargement donnée en plusieurs sous-téléchargements en fonction des options de configuration définies lors de la construction du client. Chaque sous-téléchargement a son propre appel dédié à l’opération REST. Selon les options de transfert, les bibliothèques clientes gèrent ces opérations REST en parallèle pour terminer le téléchargement complet.

max_single_get_size pour les téléchargements

Pendant un téléchargement, les bibliothèques clientes de stockage effectuent une requête de plage de téléchargement à l’aide de max_single_get_size avant d’effectuer toute autre chose. Lors de cette requête de téléchargement initiale, les bibliothèques clientes connaissent la taille totale de la ressource. Si la demande initiale a correctement téléchargé tout le contenu, l’opération est terminée. Sinon, les bibliothèques clientes continuent d’effectuer des requêtes de plage jusqu’à max_chunk_get_size jusqu’à ce que le téléchargement complet soit terminé.

Étapes suivantes