Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Low BLOB_MAX_CHUNK_DATA_SIZE leads to performance hits for max_connections=1 #337

Closed
Segsfault opened this issue Apr 2, 2015 · 2 comments
Labels
Service Attention Workflow: This issue is responsible by Azure service team. Storage Storage Service (Queues, Blobs, Files)

Comments

@Segsfault
Copy link

When using azure.storage.blobservice.get_blob_to_file, the algorithm will download a 64MB (or smaller) file in one call REST call.

However larger files are chunked in 4MB blocks. For a 65MB file this would result in 17 calls, which significantly decreases performance. For my application, changing _BLOB_MAX_CHUNK_DATA_SIZE to be the same as _BLOB_MAX_DATA_SIZE (64MB) improved performance drastically.

Not sure of all use cases to know if this will impact other applications, but if it cannot be hard coded to 64MB, perhaps allowing a chunk_size argument would help.

@huguesv
Copy link
Contributor

huguesv commented Apr 14, 2015

Thanks for letting us know about this. Looking at the node storage sdk, it appears that download chunk size may not be limited to 4MB, unless the md5 is requested. I'll do some testing.

@crwilcox
Copy link
Contributor

Issue Migrated to Azure/azure-storage-python#10

@bsiegel bsiegel added the Service Attention Workflow: This issue is responsible by Azure service team. label Sep 26, 2018
@github-actions github-actions bot locked and limited conversation to collaborators Apr 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Service Attention Workflow: This issue is responsible by Azure service team. Storage Storage Service (Queues, Blobs, Files)
Projects
None yet
Development

No branches or pull requests

4 participants