{"id":3213,"date":"2012-08-28T09:00:00","date_gmt":"2012-08-28T16:00:00","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/dataplatforminsider\/2012\/08\/28\/tpc-e-raising-the-bar-in-oltp-performance\/"},"modified":"2024-01-22T22:49:34","modified_gmt":"2024-01-23T06:49:34","slug":"tpc-e-raising-the-bar-in-oltp-performance","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/sql-server\/blog\/2012\/08\/28\/tpc-e-raising-the-bar-in-oltp-performance\/","title":{"rendered":"TPC-E \u2013 Raising the Bar in OLTP Performance"},"content":{"rendered":"
Maximizing SQL Server\u2019s performance and scalability is a complex engineering challenge. Beyond good architecture and well-designed code, we also extensively measure SQL Server to ensure that it delivers the best performance compared to previous versions and other databases. But which benchmarks do we use? That\u2019s an important question. Being super-fast on workloads that aren\u2019t relevant for real-world applications may be good for bragging rights, but doesn\u2019t help our customers. <\/span><\/p>\n We actually use many benchmarks to get a broad spectrum of coverage. In OLTP, though, our primary workload is the Transaction Processing Performance Council\u2019s <\/span>TPC-E<\/span><\/a> benchmark [1]. The <\/span>TPC<\/span><\/a> is an industry standards organization that defines performance benchmarks. TPC-E exercises a range of complex database functions that are representative of real-world workloads.<\/span><\/p>\n In this post, I want to give you some insight into why we focus on TPC-E for our engineering work and why we\u2019ve abandoned the better known, but now less relevant, TPC-C for published results and marketing. <\/span><\/p>\n TPC-C is 20 years old and has changed little since its introduction in 1992. All of the major DBMS companies have spent years picking through every detail of TPC-C. Databases have been optimized for TPC-C to such a degree that it long ago stopped driving customer-relevant engineering improvements. <\/span><\/p>\n In contrast, TPC-E is just five years old. The TPC designed it to supersede TPC-C. Microsoft was one of many companies that contributed to the development of TPC-E. We were also an early adopter of TPC-E after recognizing that TPC-C was no longer driving our engineering work in directions that benefited our customers. TPC-E has proven to be a well-constructed workload that has driven many improvements in SQL Server, surfacing performance and scalability issues that had gone undiscovered in more than a decade of running TPC-C.<\/span><\/p>\n But don\u2019t take our word for it. This IBM <\/span>whitepaper<\/span><\/a> [2] explains how TPC-E was designed to be more realistic than TPC-C. There are numerous ways, detailed in the whitepaper, in which TPC-E is far superior to TPC-C. The table below compares TPC-C and TPC-E on several dimensions. As you can see, in TPC-E the schema is substantially richer and more complex, there are twice as many transactions as TPC-C, and only TPC-E requires essential capabilities such as referential integrity and RAID protected storage. Which one looks more like your own databases?<\/span><\/p>\n