OSS performance best practices

Improve OSS data processing speed, reduce latency, and accelerate application responses by leveraging the distributed architecture of Alibaba Cloud OSS.

Change sequential prefixes to random prefixes

OSS partitions data based on the UTF-8 order of object keys to support high-concurrency requests. Sequential prefixes (timestamps or lexicographically sorted strings) concentrate files in a few partitions, overloading them. Use random prefixes instead to distribute load evenly.

When your request rate exceeds 2,000 requests per second, the following issues can occur. Each download, upload, delete, copy, or metadata retrieval counts as one operation. A batch deletion or listing of N files counts as N operations.

Hot spot partitions form: High-frequency requests concentrate on specific partitions, exhausting their I/O capacity or triggering automatic throttling.
Request rate is limited: Hot spot partitions trigger continuous data rebalancing, which increases request processing time.

Note
Rebalancing is based on real-time system status and processing capacity analysis, not fixed sharding rules. Files with sequential prefixes may remain in a hot spot partition after rebalancing.

To resolve these issues, change the sequential prefix to a random one. This distributes the object index and I/O load evenly across partitions.

Add a hexadecimal hash prefix to the object key

If you use dates and customer IDs to generate object keys, they contain a sequential timestamp prefix:
```
sample-bucket-01/2024-07-19/customer-1/file1
sample-bucket-01/2024-07-19/customer-2/file2
sample-bucket-01/2024-07-19/customer-3/file3
...
sample-bucket-01/2024-07-20/customer-2/file4
sample-bucket-01/2024-07-20/customer-5/file5
sample-bucket-01/2024-07-20/customer-7/file6
...
```
Calculate a hash (such as MD5) of the customer ID and use a few characters as the object key prefix. With a 4-character hash prefix, the keys look like this:
```
sample-bucket-01/9b11/2024-07-19/customer-1/file1
sample-bucket-01/9fc2/2024-07-19/customer-2/file2
sample-bucket-01/d1b3/2024-07-19/customer-3/file3
...
sample-bucket-01/9fc2/2024-07-20/customer-2/file4
sample-bucket-01/f1ed/2024-07-20/customer-5/file5
sample-bucket-01/0ddc/2024-07-20/customer-7/file6
...
```
A 4-character hexadecimal hash provides 16⁴ (65,536) possible combinations, allowing up to 65,536 partitions. Determine whether this is sufficient based on your request rate and the 2,000 operations per second per partition limit.

To list objects by date (for example, all objects from 2024-07-19 in `sample-bucket-01`), list all objects in the bucket by calling the ListObject API in batches, then merge results that match the desired date.

Invert the object key

A millisecond-precision UNIX timestamp as the object key is also a sequential prefix:

sample-bucket-02/1513160001245.log
sample-bucket-02/1513160001722.log
sample-bucket-02/1513160001836.log
sample-bucket-02/1513160001956.log
...
sample-bucket-02/1513160002153.log
sample-bucket-02/1513160002556.log
sample-bucket-02/1513160002859.log
...

Invert the timestamp to avoid sequential ordering. The inverted result:

sample-bucket-02/5421000613151.log
sample-bucket-02/2271000613151.log
sample-bucket-02/6381000613151.log
sample-bucket-02/6591000613151.log
...
sample-bucket-02/3512000613151.log
sample-bucket-02/6552000613151.log
sample-bucket-02/9582000613151.log
...

The first three digits represent milliseconds (1,000 possible values), the fourth changes every second, and the fifth every 10 seconds. Inversion greatly increases prefix randomness, distributing load evenly and avoiding bottlenecks.

Use byte range fetching

When downloading large files (over 100 MB) from OSS, an unstable network can interrupt the transfer. Use an HTTP Range request to fetch specific portions of a file:

Get /ObjectName HTTP/1.1
Host:examplebucket.oss-cn-hangzhou.aliyuncs.com
Date:Fri, 19 Jul 2024 17:27:45 GMT
Authorization:SignatureValue
Range:bytes=[$ByteRange]

The Range header specifies a byte range within 0 to content-length - 1. How to obtain OSS resources in segments using HTTP Range requests.

Use OSS Transfer Acceleration

Transfer Acceleration speeds up long-distance data transfers for gigabyte- or terabyte-scale files, or cross-region requests between the Chinese mainland and other regions. It routes requests to the nearest access point through smart routing, providing end-to-end acceleration. Access OSS using Transfer Acceleration.

Cache frequently accessed content

Alibaba Cloud CDN caches static content at points of presence (POPs) worldwide. Users fetch content from the nearest POP, improving access speed and reducing origin load.

When a requested file is missing or expired at a POP, CDN fetches it from the origin OSS bucket and caches it. When origin content changes, CDN automatically updates the POP caches.

This is especially useful for businesses with a global user base. Accelerate access to OSS using CDN.

Use the latest OSS SDK version

The latest Alibaba Cloud OSS SDK includes built-in performance optimizations:

New features: Includes the latest APIs, optimized algorithms, and more efficient codecs.
Error handling and retries: Automatically handles common errors (such as HTTP 503) to reduce failures and increase success rates.
Transfer management: Automatically scales connections and uses range requests to achieve high throughput.
Multi-threaded support: Process multiple requests in parallel to increase data processing speed.
Optimized memory management: Reduces unnecessary memory overhead and improves usage efficiency.
Improved compatibility: Fixes legacy issues and improves compatibility with third-party libraries and operating systems.

Download the latest SDK from SDK overview.

Use OSS and ECS in the same region

Deploy ECS instances and OSS buckets in the same region to reduce data transfer latency and improve read speeds. Same-region communication uses internal endpoints and incurs no traffic fees, allowing large-scale data transfers without bandwidth costs. Access OSS resources from an ECS instance over an internal network.

Implement timeout retries for latency-sensitive applications

OSS limits QPS for management APIs (GetService, PutBucket, GetBucketLifecycle, etc.). High request rates may trigger HTTP 503 slowdown responses. If this occurs, wait a few seconds and retry.

The total QPS for a single Alibaba Cloud account is 10,000. To request a higher limit, contact Technical Support. Even below this threshold, the server may throttle and return 503 errors if requests are concentrated on a single partition and exceed its capacity. If you randomize your request prefixes (see OSS performance and extensibility best practices), OSS automatically scales partitions to support higher QPS. You only need to wait and retry.

For large requests (over 128 MB), measure throughput and retry the slowest 5%. For small requests (under 512 KB) with typical latency in the tens of milliseconds, retry GET or PUT operations after 2 seconds. Use exponential backoff for subsequent retries (for example, 2 seconds, then 4 seconds).

For fixed-size requests with consistent response times, identify and retry the slowest 1%. A single retry often reduces latency effectively.

Achieve high throughput with horizontal scaling and parallel requests

OSS is a large-scale distributed system. Horizontally scale parallel requests to distribute load across multiple network paths.

Upload and download data in parallel across multiple threads or instances. The optimal scaling strategy depends on your application and object structure.

Start with a single request to measure bandwidth and resource usage, then determine the maximum concurrent requests. For example, if one request uses 10% of CPU, you can support up to 10 concurrent requests.

Horizontally scale storage connections

Treat OSS as a distributed system, not a single endpoint. Send multiple concurrent requests across different connections to maximize available bandwidth. OSS does not limit the number of connections to a bucket.

Increase the number of retries

If a request is slow, send a retry. Configure timeout and retry values in the OSS SDK based on your application's fault tolerance requirements.