You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Stop limiting num-connections based on num-known-IPs (Improve S3-Express performance) (#407)
**Issue:**
Disappointing S3-Express performance.
**Description of changes:**
Stop limiting num-connections based on num-known-IPs.
**Diagnosing the issue:**
We found that num-connections was never getting very high, because [num-connections scales based on the num-known-IPs](https://github.com/awslabs/aws-c-s3/blob/593c2ab24608d3e78708d51657be22f6ab99cb50/source/s3_client.c#L179). S3-Express endpoints have very few IPs, so their num-connections weren't scaling very high.
The algorithm was adding 10 connections per known-IP. On a 100Gb/s machine, this maxed out at 250 connections once 25 IPs were known. But S3-Express endpoints only have 4 unique IPs, so they never got higher than 40 connections.
This algorithm was written back when S3 returned 1 IP per DNS query. The intention was to throttle connections until more IPs were known, in order to spread load among S3's server fleet. However, as of Aug 2023 [S3 provides multiple IPs per DNS query](https://aws.amazon.com/about-aws/whats-new/2023/08/amazon-s3-multivalue-answer-response-dns-queries/). So now, we can scale up to max connections after the first DNS query and still be spreading load.
We also believed that spreading load was a key to good performance. But I found that spreading the load didn't have much impact on performance (at least now, in 2024, on the 100Gb/s machine I was using). Tests where I hard-coded a single IP and hit it with max-connections didn't differ much from tests where the load was spread among 8 IPs or 100 IPs.
I want to get this change out quickly and help S3-Express, so I picked magic numbers where the num-connections math ends up with the same result as the old algorithm. Normal S3 performance is mildly improved (max-connections is reached immediately, instead of scaling up over 30sec as it finds more IPs). S3 Express performance is MUCH improved.
**Future Work:**
Improve this algorithm further:
- expect higher throughput on connections to S3 Express
- expect lower throughput on connections transferring small objects
- dynamic scaling without a bunch of magic numbers ??? (sounds cool, but I don't have any ideas how this would work yet)
Copy file name to clipboardexpand all lines: README.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ The AWS-C-S3 library is an asynchronous AWS S3 client focused on maximizing thro
5
5
### Key features:
6
6
-**Automatic Request Splitting**: Improves throughput by automatically splitting the request into part-sized chunks and performing parallel uploads/downloads of these chunks over multiple connections. There's a cap on the throughput of single S3 connection, the only way to go faster is multiple parallel connections.
7
7
-**Automatic Retries**: Increases resilience by retrying individual failed chunks of a file transfer, eliminating the need to restart transfers from scratch after an intermittent error.
8
-
-**DNS Load Balancing**: DNS resolver continuously harvests Amazon S3 IP addresses. When load is spread across the S3 fleet, overall throughput is better than if all connections were hammering the same IP simultaneously.
8
+
-**DNS Load Balancing**: DNS resolver continuously harvests Amazon S3 IP addresses. When load is spread across the S3 fleet, overall throughput more reliable than if all connections are going to a single IP.
9
9
-**Advanced Network Management**: The client incorporates automatic request parallelization, effective timeouts and retries, and efficient connection reuse. This approach helps to maximize throughput and network utilization, and to avoid network overloads.
10
10
-**Thread Pools and Async I/O**: Avoids bottlenecks associated with single-thread processing.
11
11
-**Parallel Reads**: When uploading a large file from disk, reads from multiple parts of the file in parallel. This is faster than reading the file sequentially from beginning to end.
0 commit comments