©Copyright 2020 Cong Yan Understanding and Improving Database-Backed Applications Cong Yan A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy University of Washington 2020 Reading Committee: Alvin Cheung, Chair Magdalena Balazinska Dan Suciu Program Authorized to Offer Degree: Paul G. Allen School of Computer Science & Engineering University of Washington Abstract Understanding and Improving Database-Backed Applications Cong Yan Chair of the Supervisory Committee: Alvin Cheung Paul G. Allen School of Computer Science & Engineering From online shopping to social media network, modern web applications are used everywhere in our daily life. These applications are often structured with three tiers: the front-end developed with HTML or JavaScript, the application server developed with object-oriented programming language like Java, Python or Ruby, and the back-end database that accepts SQL queries. Latency is critical for these applications. However, our study shows that many open-source web applications suffer from serious performance issues, with many slow pages as well as pages whose generation time scales superlinearly with the data size. Prior work has been focusing on improving the performance of each tier individually, but is often not enough to reduce the latency to meet the developer’s expectation. In this thesis, I present a different optimization strategy that enables much further improvement of database-backed applications. Rather than looking into each tier separately, I focus on optimizing one tier based on how other tiers process and consume the data. In particular, I describe five projects that implement five examples of such optimization. On the database tier, I present 1) CHESTNUT, a data layout designer that generates a customized data layout based on how the application tier consumes the query result; and 2) CONSTROPT, a query rewrite optimizer that performs query optimization by leveraging the data constraint inferred from the application code. On the application tier, I present 3) QURO, a query reorder compiler that changes the query order to reduce the database locking time when processing transactions; and 4) POWERSTATION, an IDE plugin to fix performance anti-patterns in the application code which results in slow or redundant database queries. Besides cross-tier information, there is more we can use to improve the application. Then I propose 5) HYPERLOOP, a framework that leverages not only application knowledge but also the developer’s insights to make performance tradeoffs. In each project, by looking into the interaction with other tiers and even the developers, I show that many optimizations that may not be viable or effective when optimizing each one tier alone can improve the overall application performance significantly. I show the performance gain brought by these optimizations using real-world applications, then discuss future work in this direction and conclude. TABLE OF CONTENTS Page List of Figures . iv Chapter 1: Introduction . 1 1.1 Architecture of Database-Backed Applications . 3 1.2 Real-world Application Performance . 5 1.3 Thesis Contributions . 7 Chapter 2: CHESTNUT: Generating Application-Specific Data Layouts . 11 2.1 Data Representation Mismatch . 11 2.2 CHESTNUT Overview . 13 2.3 Data Layout and Query Plan . 17 2.4 Query Plan Generation . 21 2.5 Handling Write Queries . 28 2.6 Finding Shared Data Structures . 30 2.7 Evaluation . 32 2.8 Summary and Future Work . 44 Chapter 3: CONSTROPT: Rewriting Queries by Leveraging Application Constraints . 45 3.1 CONSTROPT Overview . 46 3.2 Data Constraint Detection . 48 3.3 Leveraging Data Constraints to Optimize Queries . 58 3.4 Automatic Query Rewrite and Verification . 64 3.5 Evaluation . 69 3.6 Summary and Future Work . 78 Chapter 4: QURO: Improving Transaction Performance by Query Reordering . 79 4.1 Query Order and Transaction Performance . 79 i 4.2 QURO Overview . 82 4.3 Preprocessing . 87 4.4 Reordering Statements . 89 4.5 Profiling . 99 4.6 Evaluation . 99 4.7 Summary and Future Work . 115 Chapter 5: POWERSTATION: Understanding and Fixing Performance Anti-patterns . 116 5.1 Understanding Performance Anti-Patterns . 116 5.2 POWERSTATION: IDE Plugin for Fixing Anti-Patterns . 129 5.3 Summary and Future Work . 133 Chapter 6: HYPERLOOP: View-driven Optimizations with Developer’s Insights . 134 6.1 View-driven Optimization . 134 6.2 HyperLoop Overview . 137 6.3 Priority-Driven Optimization . 139 6.4 HyperLoop’s User Interface . 140 6.5 View Designer . 144 6.6 Application-Tier Optimizer . 145 6.7 Layout Generator . 148 6.8 Summary . 150 Chapter 7: Future Work . 151 7.1 More Opportunities of Cross-Tier Optimization . 151 7.2 Improving Application Robustness . 152 7.3 Building an Intelligent Middleware . 153 7.4 Extending Techniques to Other Systems . 154 Chapter 8: Related Work . 155 8.1 Related Database Optimizations . 155 8.2 Performance Studies in ORM Applications . 159 8.3 Leveraging Application Semantics to Place Computation . 159 Chapter 9: Conclusion . 161 ii Bibliography . 164 iii LIST OF FIGURES Figure Number Page 1.1 Architecture of database-backed applications. 2 1.2 A typical architecture of a Rails application. 4 1.3 An example of blogging application built with Rails. 5 2.1 Using CHESTNUT’s data layout for OODAs. 14 2.2 Example of data layouts for Q1. A green box shows a Project object and a blue shaded box shows an Issue object. A triangle shows an index created on the array of objects. 16 2.3 Workflow of CHESTNUT ............................... 17 2.4 Example of how CHESTNUT enumerates data structures and plans for Q1. A green box shows a Project and a blue box an Issue.................... 27 2.5 Query performance comparison. Figures on the left shows the relative time of slow queries compared to the original. The original query time is shown as text on the top. Each bar is divided into the top part showing the data-retrieving time and the shaded bottom part showing the deserialization time. Figures on the right shows the summary of other short read queries and write queries. 37 2.6 Case study of Kandan-Q1. (a) shows the original query. (b) shows the corresponding SQL queries. (c) shows the data layout (left) and the query plan (right) generated by CHESTNUT. .................................... 38 2.7 Case study of Redmine-Q3. 39 2.8 Case study of Redmine-Q8. 39 2.9 Comparison with hand-tuned materialized views on individual slow queries. 40 2.10 Scaling Kandan’s data to 50G. 41 2.11 Evaluation on TPC-H. 42 3.1 CONSTROPT architecture . 48 3.2 Example program flow analysis for different types of target node. 55 3.3 Before and after query plans of replacing disjunctions with unions. The parameter :c (shown in Listing 3.11 is given a concrete value 1 in the query plan. 62 iv 3.4 Illustration of query rewrite verification . 67 3.5 Query time evaluation with PosgreSQL. Each figure shows one type of optimization. Each bar shows the speedup of one query (left y axis) and the dot on line above the bar shows the actual time of the original query in millisecond (right y axis). X-axis shows the number of query. 74 3.6 Query time evaluation with MySQL. 76 3.7 Speed up under different percentage of invalid input . 77 3.8 Evaluation on webpage performance. It shows the speedup of end-to-end webpage load time, the speedup of server time (the time spent on application server and the database), and the absolute time of the end-to-end page loading time. 77 4.1 Comparison of the execution of the original and reordered implementation of the payment transaction. The darker the color, more likely the query is going to access contentious data. 84 4.2 Architecture and workflow of QURO ......................... 85 4.3 Performance comparison: varying data contention . 100 4.4 Performance comparison: varying number of threads for TPC-C benchmark . 101 4.5 Performance comparison: varying number of threads . 104 4.6 Self-relative speedup comparison . 106 4.7 Execution of trade update transactions T1 and T2 before and after reordering. Deadlock window is the time range where if T2 starts within the range, it is likely to deadlock with T1. 109 4.8 TPC-C worst-case . 110 4.9 Comparison with stored procedure. 110 4.10 Throughput comparison by varying buffer pool size . 111 4.11 Performance comparison of TPCC transactions among original implementation under OCC, MVCC, and variants of 2PL. 112 4.12 Execution of transaction T1 and T2 under different concurrency control schemes. 113 5.1 Action Flow Graph (AFG) example . 117 5.2 Performance gain by caching of query results. 119 5.3 Performance gain after applying all optimizations . 124 5.4 Transfer size reduction . 125 5.5 Pagination evaluation. The original page renders 1K to 5K records, as opposed to 40 records per page after pagination. 126 v 5.6 Caching evaluation on paginated webpages. p1 and p2 refer to the current the next pages, respectively. (we observed no significant latency difference among the pages that are reachable from p1). The x-axis shows.