Note:
COS has already achieved high QPS through its underlying index dispersion mechanism. If you require higher QPS performance, please contact us. In daily file organization, we still recommend that you follow the guidelines in this document to avoid overly concentrated index storage methods.
Feature Overview
This document describes the best practices for optimizing the request rate performance in COS.
COS supports a typical workload capacity of 30,000 PUT or GET requests per second. If your workload exceeds the threshold, you can follow this guide to expand and optimize your request rate performance.
Note:
Request load refers to the number of requests initiated per second, not the number of concurrent connections. This means that you can still send hundreds of new connection requests within 1 second while maintaining thousands of connections.
COS supports performance expansion to provide a higher request rate. In case of a high GET request load, we recommend you use COS in combination with CDN. For more information, see Overview. If the overall request rate of a bucket is expected to exceed 30,000 PUT/GET requests per second, contact us to prepare for the workload and avoid exceeding the request limit.
Note:
If your mixed request workload only occasionally reaches 30,000 requests per second and does not exceed 30,000 requests per second during bursts, you may not need to follow this guide.
Practical Steps
Mixed request load
When a large number of objects need to be uploaded, the object key you select may cause performance issues. Below is a brief description of how COS stores object key values.
Tencent Cloud maintains bucket and object key values as indexes in each service region of COS. Object keys are stored in the UTF-8 binary order in multiple index partitions. Due to such a large number of key values, using timestamps or alphabetical order, for example, may exhaust the read/write performance capacity of the partition where the key values are located. Taking the bucket path
examplebucket-1250000000.cos.ap-beijing.myqcloud.comas an example, below are some cases that may exhaust the index performance capacity:20170701/log120000.tar.gz20170701/log120500.tar.gz20170701/log121000.tar.gz20170701/log121500.tar.gz...image001/indexpage1.jpgimage002/indexpage2.jpgimage003/indexpage3.jpg...
If your typical workload exceeds 30,000 requests per second, you should avoid using sequential key values as shown in the above case. When you need to use characters such as sequential numbers, dates, or time values as object keys, you can add random prefixes to key names, so as to manage key values in multiple index partitions and improve the centralized load performance. Below are some methods for adding a random element to key values.
Note:
All the following methods can be used to improve the access performance of a single bucket. If the typical load of your business exceeds 30,000 requests per second, you still need to contact us to prepare for your business load in advance.
Adding hexadecimal hash prefixes
The most direct way to increase the object key randomness is to add a hash string prefix at the beginning of the key name. For example, when uploading an object, calculate the SHA1 or MD5 hash of the path key value and add a few characters as a prefix to the key name. Generally, a hash prefix with a length of 2–4 characters will suffice.
faf1-20170701/log120000.tar.gze073-20170701/log120500.tar.gz333c-20170701/log121000.tar.gz2c32-20170701/log121500.tar.gz
Note:
As key values in COS are indexed in the UTF-8 binary order, you may need to initiate 65,536 GET Bucket operations to get the original complete
20170701 prefix structure.Adding enumerated value prefixes
If you still want to ensure that your object keys are easily retrievable, you can enumerate prefixes based on file type to help group your objects. Prefixes with the same enumeration value share the performance of the index partition where they are located.
logs/20170701/log120000.tar.gzlogs/20170701/log120500.tar.gzlogs/20170701/log121000.tar.gz...images/image001/indexpage1.jpgimages/image002/indexpage2.jpgimages/image003/indexpage3.jpg...
If the access load for an enumerated prefix remains at over 30,000 requests per second, you can refer to the previous method to add a hash prefix after the enumerated value to implement multiple index partitions. This can further improve the read/write performance.
logs/faf1-20170701/log120000.tar.gzlogs/e073-20170701/log120500.tar.gzlogs/333c-20170701/log121000.tar.gz...images/0165-image001/indexpage1.jpgimages/a349-image002/indexpage2.jpgimages/ac00-image003/indexpage3.jpg...
Reversing the key name string
When you need to use incremental IDs or dates or upload a large number of objects with successive prefixes in a single request, refer to the following method:
20170701/log0701A.tar.gz20170701/log0701B.tar.gz20170702/log0702A.tar.gz20170702/log0702B.tar.gz...id16777216/album/hongkong/img20170701121314.jpgid16777216/music/artist/tony/anythinggoes.mp3id16777217/video/record20170701121314.movid16777218/live/show/date/20170701121314.mp4...
The naming method for key values shown above easily exhausts the performance capacity of index partitions where the key values prefixed with
2017 and id are located. In this case, reverse part of the key prefix to allow for a certain degree of randomness.10707102/log0701A.tar.gz10707102/log0701B.tar.gz20707102/log0702A.tar.gz20707102/log0702B.tar.gz...61277761di/album/hongkong/img20170701121314.jpg61277761di/music/artist/tony/anythinggoes.mp371277761di/video/record20170701121314.mov81277761di/live/show/date/20170701121314.mp4...
High GET request load
If your workload primarily involves GET requests (i.e., download requests), in addition to the above guidelines, we recommend you use COS in combination with CDN.
CDN has edge cache nodes around the globe that can be used to minimize the latency and improve the speed of content delivery to users. Frequently accessed files can be cached with the prefetch feature, thus reducing the number of GET requests forwarded to the COS origin. For more information, see Overview.