Time: 12:05 - 12:55
Database performance is often measured as the maximal transaction throughput, typically reported by benchmarks as an average number of transactions-per-second (tps). We show that using this as the only measure of performance can lead to unexpected or even detrimental behaviors when one gets a closer look at what is happening. We argue that latency (the time to process a transaction, typically in ms), for a database engine not necessarily running at maximal throughput, must be considered: think for instance of a responsive web application which consults and updates a database. We then analyze the path of a transaction to explain its latency, and then discuss how to reduce this latency of database transactions as seen from the client application, using obvious and possibly less obvious tricks.