REVIEW 1 cited by
8 Years of Optimizing Apache Otava: How disconnected open source developers took an algorithm from n3 to constant time
Not yet reviewed by Pith; the record is open.
This paper has not been read by Pith yet. Machine review is queued; the pith claim, tier, and objections will appear here once it completes.
SPECIMEN: schema-true, not a live event
T0 review · schema-true
One-sentence machine reading of the paper's core claim.
pith:XXXXXXXX · record.json · timestamp
8 Years of Optimizing Apache Otava: How disconnected open source developers took an algorithm from n3 to constant time
read the original abstract
As the project now known as Apache Otava (incubating) makes it first release, we look back over the past 8 years that the codebase was developed by a rather uncoordinated, loosely connected group of performance engineers at MongoDB, Datastax, Confluent, Nyrkio and others. Ever since the first publication (Daly 2020), developers of the code base now known as Apache Otava (incubating), have continuosly improved its performance. Even when a contributor's primary motivation was to add functionality, it seems like they couldn't help themselves but to also make some performance optimizations while at it. When developing the Nyrkio web service to provide change detection for performance testing, we have observed that Otava had become fast enough that it was almost feasible to compute change points synchronously, as the user is browsing test results in a web browser. Inspired by this, we have developed and contributed a new optimization for the common case where new data points are appended to the end of the series. This is now the 7th generation of performance optimizations in Otava. These improvements have been done over the past 8 years of development, by disconnected individuals at different employees. Taken together, the historical optimizations and those published in this paper, represent a 18 000 to 300 000 speedup over the original by the book implementation of (Matteson and James 2014). In the language of computational complexity, an evolution from O (n3) to O (1) (constant time). The ability to compute and recompute change points in real-time unlocks new opportunities in the user experience.
Forward citations
Cited by 1 Pith paper
-
Exploring Statistical Change Point Detection Techniques for Performance Anomaly Detection at Mozilla
Ensemble voting strategies for change point detection improve F1-score by 11% over Mozilla's T-test method on a new ground-truth dataset of 174 performance time series annotated by practitioners.
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.