Replies: 1 comment 3 replies
-
|
Using the S3 (Timestamps) connection profile 1 will read metadata for every file to be displayed. That causes an additional request to the S3 API that will degrade performance as described. However, you only need to use the profile when you want to view the timestamps set in the browser, but they are always set with the generic S3 connection profile for files uploaded. I have opened 2 to fix our documentation in this regard. Footnotes |
Beta Was this translation helpful? Give feedback.
-
|
Ok, thanks. Would Backblaze B2 act the same way? |
Beta Was this translation helpful? Give feedback.
-
|
B2 does not require an additional API request to obtain file info but includes this metadata when listing objects and is thus not affected by the same performance drawback. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent, thank you! |
Beta Was this translation helpful? Give feedback.
-
I have some buckets on R2 with several thousand files each. When I double-click the bucket in Cyberduck, it takes a long time to list the bucket contents. For example, a bucket with 3600 files took 7 minutes. A bucket with 7600 files took 31 minutes.
To Reproduce
Expected behavior
I expect/hope performance on R2 would be about the same as Rackspace Cloud Files
Desktop (please complete the following information):
Additional context
Listing and uploading to a bucket with just a few files is as fast as I'd expect.
The R2 buckets are a clone of buckets we have on Rackspace Cloud Files and Cyberduck does just fine there.
I am using an R2 profile with S3 timestamps enabled.
Log Files
If needed, I can supply log files or snippets. I can say that when I list my "doc13" bucket (3600 files) on Rackspace with debugging enabled, the log file is 905 KB. When I list my "doc13" bucket on R2, the log file is 31.5 MB. The big difference is that R2 has a HEAD request for every file but Rackspace doesn't.
Beta Was this translation helpful? Give feedback.
All reactions