This sounds like you're blaming dynamo for you/your stack's inability to handle connections / connection pooling.
I don’t have p99 times in front of me right this second but it’s definitely lower than 20ms for reads and likely lower for writes. (EC2 in VPC).
I am running https://cloud-canary.com a service where I monitor AWS primary services for latency and availability.
It comes with a lot of data.
For instance this is the latency I see doing operations against Dynamo.
https://cloudcanary.grafana.net/public-dashboards/c53e2092d6...
Little bit of well meaning advice: This needs copy editing -- inconsistent use of periods, typos, grammar. Little crap that doesn't matter in the big picture, but will block some from opening their wallets. :) ("OpenTeletry", "performances", etc.)
All in all this is quite cool, and I hope you get some customers and gather more data! (a 4k object size in S3 doesn't make sense to measure, but 1MB might be interesting. Also, check out HDRHistogram, it might be relevant to your interests)
Any feedback is appreciated!
I pick 4k as a no-op against S3, something that very little time but still does some work.
I will definitely consider to increase it!
I'll definitely update it!
Numbers without units are dangerous in my opinion.
If Amazon said they didn't use DAX that day I would say they were lying.
The average consumer or startup is not going to squeeze out the performance of Dynamo that AWS is claiming that they have achieved.
In fact, it might have been fairer in Ruby if they didn't hard-code the net client (Net/HTTP). I imagine performance could have been boosted by injecting an alternative.