This section describes the best practices for request rate optimization in COS.
COS supports a typical workload capacity of 100 PUT/LIST/DELETE requests per second or 400 GET requests per second. If your workload exceeds the threshold, you can follow this guide to optimize your request rate.
Note:
The request load indicates the number of requests initiated per second rather than the number of concurrent connections. In other words, you can send hundreds of new connection requests per second while maintaining thousands of existing connections.
COS supports performance scaling to support higher request rates. If the request rate of a bucket is expected to exceed 500 PUT/LIST/DELETE requests per second, you are advised to contact us to prepare for the workload and avoid request limits.
Note:
If you have a mixed request load that only occasionally reaches 500 requests per second and does not exceed 800 requests per second during bursts, you can ignore this guide.
Mixed Request Load
When a large number of objects need to be uploaded, the object key you select may cause performance issues. The following simply describes how COS stores object key-values.
In each service region of COS, the cloud platform maintains key-values of buckets and objects as indexes. The object keys are stored in UTF-8 binary order across multiple index partitions. For a large number of key-values, using timestamps or alphabetical order may exhaust the read/write performance of the partition where the key-values are stored. The bucket path testbucket-123454321.cos.city.yfm4.fsphere.cn is used as an example. The following lists some cases that may exhaust index performance.
20170701/log120000.tar.gz
20170701/log120500.tar.gz
20170701/log121000.tar.gz
20170701/log121500.tar.gz
...
image001/indexpage1.jpg
image002/indexpage2.jpg
image003/indexpage3.jpg
...
If the typical load of your business exceeds 500 requests per second, you should avoid using sequential key-values as mentioned in the above case. When your business should use sequential numbers or date-time characters as object keys, you can add random prefixes to the object key names. This ensures key-value management across multiple index partitions and improves the performance under concentrated loads. The following describes some methods to increase randomness in key-values.
All of the following methods can enhance the access performance of a single bucket. If the typical load of your business exceeds 500 requests per second, in addition to the following methods, you still need to contact us to make preparations for your business load in advance.
Adding Hexadecimal Hash Prefixes
The most direct way to increase the randomness of object keys is to add a hash string to the beginning of an object key name as a prefix. For example, when an object is uploaded, you can perform SHA1 or MD5 hash calculation on the path key-value, pick several characters as a prefix, and add it to the key name. Usually, a hash prefix of 2 to 4 characters can meet the requirements.
faf1-20170701/log120000.tar.gz
e073-20170701/log120500.tar.gz
333c-20170701/log121000.tar.gz
2c32-20170701/log121500.tar.gz
Note:
The COS key-values are indexed in UTF-8 binary order. When performing the operation of listing objects (GET Bucket), you might need to initiate 65,536 such operations to obtain the original complete prefix structure of 20170701.
Adding Enumerated Value Prefixes
To ensure that your object keys are easily retrievable, you can enumerate some prefixes based on your file type to group your objects. Prefixes with the same enumeration value share the performance of the index partition where they are located.
logs/20170701/log120000.tar.gz
logs/20170701/log120500.tar.gz
logs/20170701/log121000.tar.gz
...
images/image001/indexpage1.jpg
images/image002/indexpage2.jpg
images/image003/indexpage3.jpg
...
If the access load under the same enumerated prefix remains high, exceeding 500 requests per second, you can refer to the method mentioned above to add a hexadecimal hash prefix after the enumerated value in multiple index partitions for higher read/write performance.
logs/faf1-20170701/log120000.tar.gzlogs/
e073-20170701/log120500.tar.gz
logs/333c-20170701/log121000.tar.gz
...
images/0165-image001/indexpage1.jpg
images/a349-image002/indexpage2.jpg
images/ac00-image003/indexpage3.jpg
...
Reversing the Key Name String
When your business has to use incremental IDs or dates or needs to upload a large number of objects with successive prefixes at a time, use the following typical method:
20170701/log0701A.tar.gz
20170701/log0701B.tar.gz
20170702/log0702A.tar.gz
20170702/log0702B.tar.gz
...
id16777216/album/city/img20170701121314.jpg
id16777216/music/artist/tony/anythinggoes.mp3
id16777217/video/record20170701121314.mov
id16777218/live/show/date/20170701121314.mp4
...
The above key-value naming method easily depletes the index partition where key-values with prefixes 2017 and id are located. In this case, reversing part of the key-value prefixes to ensure randomness.
10707102/log0701A.tar.gz
10707102/log0701B.tar.gz
20707102/log0702A.tar.gz
20707102/log0702B.tar.gz
...
61277761di/album/city/img20170701121314.jpg
61277761di/music/artist/tony/anythinggoes.mp3
71277761di/video/record20170701121314.mov
81277761di/live/show/date/20170701121314.mp4
...