Sloth

Abstract

Many web applications store persistent data in databases. During execution, such applications spend a significant amount of time communicating with the database for retrieval and storing of persistent data over the network. These network round-trips represent a significant fraction of the overall execution time for many applications (especially those that issue a lot of database queries) and, as a result, increase their latency. While there has been prior work that aims to eliminate round-trips by batching queries, they are limited by (1) a requirement that developers manually identify batching opportunities, or (2) the fact that they employ static program analysis techniques that cannot exploit many opportunities for batching, as many of these opportunities require knowing precise information about the state of the running program. In this article, we present S loth , a new system that extends traditional lazy evaluation to expose query batching opportunities during application execution, even across loops, branches, and method boundaries. Many such opportunities often require expensive and sophisticated static analysis to recognize from the application source code. Rather than doing so, S loth instead makes use of dynamic analysis to capture information about the program state and, based on that information, decides how to batch queries and when to issue them to the database. We formalize extended lazy evaluation and prove that it preserves program semantics when executed under standard semantics. Furthermore, we describe our implementation of S loth and our experience in evaluating S loth using over 100 benchmarks from two large-scale open-source applications, in which S loth achieved up to a 3 × reduction in page load time by delaying computation using extended lazy evaluation.

Implicit Parallelism through Deep Language Embedding

“…Driver to Dataflows. To integrate data motion between the driver and the dataflows, we wrap the dataflows generated in Section 4.3.1 in special objects called thunks [16]. A thunk object of type Thunk[A] wraps an abstract dataflow that results in a value of type A.…”

“…It then reads a list of blacklisted mail servers (line 2). The loop at lines 7-25 applies different classifiers (lines 9-12) and finds the one that produces the least amount of non-spam emails sent from blacklisted servers (lines [15][16][17][18]. Applicable Optimizations.…”

“…while (not delta.empty()) { 6 val msgs = for(s <-delta; n <-s.neighborIDs) 7 yield Message(n, s.component) 8 9 val updates = for(g <-msgs.groupBy(_.receiver)) 10 yield Updt(g.key, g.values.map(_.component).max()) We read and filter lineitem by the specified date in lines 2-5 before grouping and performing the final aggregation in lines 8-32. We thereby first group lineitem by returnFlag and lineStatus (line 9) and then specify the aggregate expressions in the actual comprehension head (lines [12][13][14][15][16][17][18][19]. Note that in other dataflow APIs the programmer would have to perform the Fold-Group Fusion rewrite manually in order to achieve the same performance.…”

“…In line 13 we return the order priority for all matching tuples. Finally, we group the resulting tuples by their priority and count them (lines [16][17][18]. In this section we show a set of experiments that analyze the effect of the Fold-Group Fusion (GF) optimization that we introduced in Section 4.2.2.…”