To optimize the performance of your application when the application uses OSS, we recommend that you follow the guidelines described in this topic.
Measure performance indexes
Evaluate the performance of different ECS instance types based on your requirements on CPU and network throughput. For more information about the types of ECS instances, see Overview. In addition, we recommend that you use analysis tools to measure the DNS query time, latency, and data transmission speed.
Distribute requests to multiple connections
It is common to distribute requests to multiple connections for high performance in the design of applications. When you develop a high-performance application, you can use OSS as a large-scale distributed storage system instead of a single storage node such as a traditional storage server. You can send multiple concurrent requests to OSS to improve application performance. You can distribute requests to multiple connections to fully use the bandwidth provided by OSS. OSS does not impose limits on the number of connections to a bucket.
Use range download
You can specify the Range header in a GetObject request to obtain the specified bytes of an object. Only data within the specified range is transferred. You can initiate concurrent requests to obtain data within different ranges of the same object. Instead of sending a single request to obtain an entire object, you can send concurrent requests to obtain an object by range for higher throughput. In addition, if you obtain only data within a small range of a large object, your application takes less time to retry a request when no response is returned for the request. For example, you can set the range size to 512 KB or 1 MB. Note that the boundaries of the byte ranges in different requests must be aligned. For more information, see GetObject.
Increase allowed number of retries
Due to its large scale, OSS may take a long time to respond to a request when the request is sent for the first time. In this case, you can retry the request. You can use OSS SDKs to configure the timeout period and the allowed number of retries for requests based on your requirements.
Keep OSS buckets and ECS instances in the same region
The name of a bucket is globally unique in OSS. You must specify the region of a bucket when you create the bucket. The name and region of a bucket cannot be changed after the bucket is created. To reduce latency and data transmission costs, we recommend that you access an OSS bucket by using ECS instances in the same region as the bucket. For more information, see Access to OSS resources from ECS instances by using the internal endpoint of OSS.
Use transfer acceleration
The transfer acceleration feature provided by OSS is suitable for the regular transmission of large objects of gigabytes or terabytes in size over a long distance. OSS uses data centers distributed around the globe to implement transfer acceleration. When a request is sent to your bucket, it is parsed and routed to the data center where the bucket resides over the most optimal network path and protocol. This way, objects can be transferred over a long distance in a fast and secure manner. For more information, see Transfer acceleration.
You can visit The Comparison of OSS Direct Data Transfer and Accelerated Data Transfer in Different Regions to compare the access speeds when you use the accelerate and default endpoints to access OSS in different regions.
Use the latest versions of OSS SDKs
OSS SDKs provide built-in support for multiple performance optimization guidelines. OSS SDKs provide simple API operations and are updated on a regular basis to follow the latest best practices. For example, OSS SDKs support built-in retry logic for network errors on the client and server to adapt to different network conditions. OSS SDKs also provide advanced data transmission API operations that follow best practices for the upload or download of large objects.