TL DR: Aurora has the lowest (fastest) and most stable COMMIT latency. Point being: if your application uses multi-statement transactions, COMMIT and TPS can be more important than individual query response time when the queries are fast but the storage is slow. If, for example, you have 48 threads (clients), you’ll get about 50 * 48 = 2,400 TPS. Given that latency, the transaction is limited to about 50 TPS (1,000 ms / 20 ms = 50) per thread.
Aurora sql vs mysql update#
The SELECT and UPDATE take almost no time, but the COMMIT takes a full 20 milliseconds because it’s writing and flushing to an EBS volume, for example. Presuming negligible lock waits and intra-query delays (caused by the application), TPS is limited by how fast MySQL can finish the transaction on COMMIT.įor example, in the cloud a transaction might have these response times: Readers of my book know that normally I use (and insist upon) the term response time, not latency, because response time is not a delay inherit in a system.ĬOMMIT latency is also important because it affects transaction throughput (transactions/second ). I use the term latency specifically because storage has true latency: delay inherent in a system. In the cloud, storage is usually network-backed, so COMMIT latency can be orders of magnitude higher than locally-attached SSDs-milliseconds versus microseconds. Therefore, CPU and memory (and a few other concerns) affect query response time before COMMIT, but on COMMIT response time is largely a result of how fast the storage system can physically write and flush. Why COMMIT Latency?ĬOMMIT is when MySQL incurs storage latency to make data changes durable.īefore that, reads and writes are ideally (but not always) in-memory operations. Let’s examine COMMIT latency on Aurora v2 (MySQL 5.7) vs.
0 kommentar(er)
