- 최신
- 최다 투표
- 가장 많은 댓글
The latency that you are observing includes network and client latency. If you are interested in just the DynamoDB latency, the Cloudwatch metric https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#SuccessfulRequestLatency will provide you with the actual DynamoDB latency.
If you wish to determine the full round-trip latency from the client to DynamoDB and back, you may want to run the queries from an EC2 machine running inside a VPC that has a VPC endpoint for DynamoDB configured, so the traffic goes over the Amazon network and not over the internet.
DynamoDb also has DynamoDB Accelerator (DAX) that can improve read latency - https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.concepts.html
The latency you are witnessing is due to the ad-hoc queries you are running. DynamoDB makes use of metadata caching to reduce the latency for your requests, however, when you make only a small number of requests then your metadata cache is stale, meaning your request must do things like AuthN/AuthZ, along with other off the box hops.
DynamoDB aims to deliver single digit millisecond response time of singleton operations, this would be quite tricky to achieve via the Web Console there are only so many requests you can submit in a given amount of time. Your Go app should be able to reduce the latency much much further once you make frequent requests to DynamoDB. You can find more information here to help you make effective decisions to reduce latency.
Thanks, I was hoping that the response time returned by the AWS Console PartiQL editor was not taking into account the latency.