Swift uploads through Glance using ridiculously small chunks
Bug #909533 reported by
Ewan Mellor
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glance |
Fix Released
|
High
|
Jay Pipes |
Bug Description
Ever since 57c4e9b6c686f13
By the looks of it, the code before this would have attempted 200 MB reads, which would have been almost as bad -- you'd get 200 MB allocated for buffering per incoming stream.
Changed in glance: | |
status: | New → In Progress |
assignee: | nobody → Ewan Mellor (ewanmellor) |
Changed in glance: | |
assignee: | Ewan Mellor (ewanmellor) → Jay Pipes (jaypipes) |
Changed in glance: | |
status: | Fix Committed → Fix Released |
Changed in glance: | |
milestone: | essex-3 → 2012.1 |
To post a comment you must log in.
"By the looks of it, the code before this would have attempted 200 MB reads, which would have been almost as bad -- you'd get 200 MB allocated for buffering per incoming stream."
Firstly, it would be great to leave the snark at the door, Ewan...
Secondly, the original code only used 200MB reads when the image size passed to the storage backend was >5GB. So saying that every incoming stream would allocate 200MB is not true...
It seems that, as you say, the 57c4e9b6c686f13 03c815698cc68b9 5bf9b033e7 patch removed the multiplication of the config variable by (1024 * 1024), resulting in, as you say, "ridiculously small chunks". The solution is to return the multiplication of the megabyte to the config value.
FYI, 200MB is the default segment size for large object uploads in Swift, which is why 200MB was used originally.