AWS amazondynamodb documentation change
Summary
Updated latency troubleshooting guidance with more technical details about connection reuse, eventually consistent read benefits, request hedging implementation, and timeout configuration warnings
Security assessment
Changes focus on performance optimization and reliability improvements. While timeout configuration warnings mention availability risks, there's no evidence of addressing a specific security vulnerability. The connection reuse section emphasizes HTTPS (security standard) but doesn't introduce new security information.
Diff
diff --git a/amazondynamodb/latest/developerguide/TroubleshootingLatency.md b/amazondynamodb/latest/developerguide/TroubleshootingLatency.md index 10606ea23..161f368fc 100644 --- a//amazondynamodb/latest/developerguide/TroubleshootingLatency.md +++ b//amazondynamodb/latest/developerguide/TroubleshootingLatency.md @@ -38 +38 @@ Consider one or more of the following strategies to reduce latency: - * **Reuse connections:** DynamoDB requests are made via an authenticated session which defaults to HTTPS. Initiating the connection takes time so the latency of the first request is higher than typical. Requests over an already initialized connection deliver DynamoDB's consistent low latency. For this reason, you may wish to make a "keep-alive" `GetItem` request every 30 seconds if no other requests are made, to avoid the latency of establishing a new connection. + * **Reuse connections:** DynamoDB requests are made via an authenticated session over HTTPS by default. Initiating the connection requires multiple round-trips and takes time so the latency of the first request is higher than following requests that reuse the connection. Requests over an already initialized connection deliver DynamoDB's consistent low latency. To avoid the latency overhead of establishing new connections, you may want to implement a "keep-alive" mechanism by sending a `GetItem` request every 30 seconds if no other requests are made. @@ -40 +40 @@ Consider one or more of the following strategies to reduce latency: - * **Use eventually consistent reads:** If your application doesn't require strongly consistent reads, consider using the default eventually consistent reads. Eventually consistent reads are lower cost and are also less likely to experience transient increases in latency. For more information, see [DynamoDB read consistency](./HowItWorks.ReadConsistency.html). + * **Use eventually consistent reads:** If your application doesn't require strongly consistent reads, consider using the default eventually consistent reads. Eventually consistent reads have lower cost and can come from multiple availability zones, allowing selection of an availability zone co-located to the requester which decreases latency. For more information, see [DynamoDB read consistency](./HowItWorks.ReadConsistency.html). @@ -42 +42 @@ Consider one or more of the following strategies to reduce latency: - * **Implement request hedging:** For very low p99 latency requirements, consider implementing request hedging. With request hedging, if the initial request doesn't receive a response quickly enough, send a second equivalent request and let them race. For writes, use timestamp-based ordering to ensure hedged requests are treated as occurring at the time of the first attempt, preventing out-of-order updates. This improves tail latency at the cost of some extra requests. This approach has been discussed in [Timestamp writes for write hedging in Amazon DynamoDB](https://aws.amazon.com/blogs/database/timestamp-writes-for-write-hedging-in-amazon-dynamodb). + * **Implement request hedging:** For very low p99 latency requirements, consider implementing request hedging. With request hedging, if the initial request doesn't receive a response quickly enough, send a second equivalent request and let them race, first response wins. This improves tail latency at the cost of some extra requests. You can decide how long to wait before sending the second request. Hedging is easier for reads. For writes, use timestamp-based ordering to ensure hedged requests are treated as occurring at the time of the first attempt, preventing out-of-order updates. This approach has been discussed in [Timestamp writes for write hedging in Amazon DynamoDB](https://aws.amazon.com/blogs/database/timestamp-writes-for-write-hedging-in-amazon-dynamodb). @@ -52 +52 @@ Consider one or more of the following strategies to reduce latency: -Default SDK behaviors are optimized for most applications. However, you can implement a fail-fast strategy and adjust timeout settings. Requests taking significantly longer than normal are less likely to ultimately succeed. By failing fast and retrying, you may quickly succeed through a different path. +Default SDK behaviors are optimized for most applications. However, you can implement a fail-fast strategy and adjust timeout settings. Requests taking significantly longer than normal are less likely to ultimately succeed. By failing fast and retrying, you may quickly succeed through a different path. This is similar to request hedging but ends the first request instead of allowing it to proceed. @@ -54 +54 @@ Default SDK behaviors are optimized for most applications. However, you can impl -While lowering network or socket timeout values can improve responsiveness, it comes with risks. With aggressive settings you may fail fast when your client struggles to connect to and process data from DynamoDB, but misconfiguration can lead to client-induced availability issues. For example, a 20-millisecond socket timeout could cause connection errors during network latency spikes, such as when approaching Amazon EC2 instance bandwidth limits for single-flow traffic. Carefully weigh the benefits of lower timeouts against potential risks to application availability. +Avoid setting timeout values too low. Overly low timeouts can lead to client-induced availability issues. For example, a 50-millisecond socket timeout could cause connection errors during network latency spikes, such as when approaching Amazon EC2 instance bandwidth limits for single-flow traffic. Carefully weigh the benefits of lower timeouts against potential risks to application availability, and prefer hedging to short timeouts.