Pith. sign in

REVIEW 5 major objections 4 minor 42 references

Generating representative macrobenchmark microservice systems from distributed traces with Palette

T0 review · 5 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Palette turns distributed traces into runnable, representative microservice benchmark systems by modeling the observed system as a graphical causal model.

desk verdict A clean, well-written design for synthesizing microservice benchmarks from traces, but with no implementation and a deterministic latency model that cannot reproduce variance, the load-bearing representativeness claim is unsupported. read the letter →

arxiv 2506.06448 v1 pith:MLVYAGDV submitted 2025-06-06 cs.DC

Vaastav Anand , Matheus Stolet , Jonathan Mace , Antoine Kaufmann This is my paper
classification cs.DC
keywords microservicesdistributedtracinggraphicalcausalmodelsbenchmarkgenerationmacrobenchmarkssystemtopologyinterventionexperimentstrace-driven
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that distributed traces, which record every API call, its latency, and its caller-callee relationships, carry enough information to reconstruct a runnable stand-in for the original service. It proposes Palette, which digests a trace dataset into a 'system topology' — a directed graph of services and APIs, a probabilistic finite automaton of each API's execution paths, and a graphical causal model of how parent latencies and call decisions shape downstream behavior. From this topology it generates a deployable macrobenchmark whose runtime samples the causal model, conditioned on live measurements, to reproduce the original system's structure and performance. If the approach works, researchers who only have traces — not production access — can run intervention experiments on systems that match production scale, topology, and execution patterns.

What carries the argument

The load-bearing object is the system topology, a three-layer abstraction: a directed graph of APIs and services; a probabilistic finite automaton per API encoding how dependency calls are ordered (sequential, concurrent, or chosen) and at what probabilities; and a graphical causal model (GCM) per API whose nodes are latency (or other property) variables plus Bernoulli call indicators, with causal equations that combine parent values according to the PFA's behavior type. The GCM is the mechanism that lets the generated system sample execution times and payloads conditioned on the state of the call chain instead of from marginal statistics, and its fitted coefficients carry the performance characteristics of the original system into the benchmark.

What would settle it

Compare the per-service latency distributions, branching probabilities, and call-graph fan-out of a generated system, running the trace workload, against a held-out portion of the original trace data; if the regenerated tail latencies, multi-modal peaks, or dependency-call ratios differ beyond sampling error, the representativeness claim fails.

Watch

Extended reading notes

Core claim

The central claim is that a system topology, learned purely from distributed traces, is a faithful-enough encoding that a generated system will be representative of the original. Structure is captured as a directed graph whose vertices are APIs and whose edges are caller-callee relations, partitioned into services; execution behavior is captured per API by a probabilistic finite automaton that distinguishes sequential and concurrent dependency calls; performance is captured per API by a graphical causal model with Bernoulli 'called' nodes and linear causal equations (weighted sums of parent latencies plus an intercept). Palette fits the coefficients to the observed traces, converts the topology into code, and at runtime plugs measured latencies into the causal equations so sampled work and delays reflect the current call context. The paper asserts that because the GCM infers causal effects from observed data, any new sample it generates is representative of the original data (Section 2.3).

Load-bearing premise

The load-bearing premise is that a simple causal model fit to observed traces — weighted sums of parent latencies plus an intercept, with Bernoulli call indicators — will generate new samples, including tail latencies and multi-modal behavior, that are representative of the original system, a claim the paper states but does not validate on held-out data.

Editorial extensions

If this is right

  • If representative, researchers can run interventions (modify topology, specs, instantiation) while holding everything else fixed, because the model isolates each causal factor.
  • Generated systems inherit production-scale fan-in and fan-out and multi-modal latency from traces rather than the limited design space of hand-built open-source benchmarks.
  • Trace datasets already collected by large operators become reusable experimental infrastructure, not just post-mortem artifacts.
  • The same pipeline extends to other performance properties such as payload sizes by adding nodes and equations; live measurements plus baggage propagation let the runtime steer behavior back toward the observed joint distribution when hardware changes cause divergence.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next test is comparing the generated system's end-to-end latency and error distributions against held-out traces from the same production system, under identical workload; the paper does not report such validation.
  • The linear additive causal equations in Table 2 will likely struggle with strongly non-linear or threshold-like dependencies (e.g., queueing effects that kick in at high concurrency); those cases would need richer equations or latent states.
  • Palette's GCM models a single request's causal path and does not model cross-request contention or load-dependent queueing, so generated systems may be representative only up to the boundary of independent requests.
  • One could test the abstraction's portability by deriving a topology from a public trace set, generating a system, and measuring whether an intervention's relative effect (e.g., adding a slow dependency) matches the effect predicted by the causal model.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 4 minor

Summary. The paper proposes Palette, a design for generating runnable microservice benchmark systems from distributed traces. It introduces a "system topology" abstraction that combines a directed graph of services and APIs, a probabilistic finite automaton (PFA) modeling execution paths, and a graphical causal model (GCM) for performance properties such as latency. Section 3 describes a pipeline that processes traces, builds and fits GCM equations (Table 2), converts the topology into specifications, generates code with Blueprint, and uses a GCM-based runtime to sample latency values and propagate causal baggage. The central assertion, stated in Section 2.3, is that because a GCM is fit to observed data, any new sample generated by the GCM is representative of the original data. The paper presents no implementation, no experiments, and no comparisons; the only figure shows a failure of a simple statistical baseline rather than a result produced by Palette.

Significance. If the central representativeness claim were established, Palette would address a recognized need for representative, configurable microservice benchmarks for intervention experiments. The proposed decomposition into a call graph, a PFA, and a GCM is a reasonable and extensible framing, and the paper explicitly identifies the design dimensions that matter for benchmark use cases, such as topology, execution paths, and tail latencies. However, in its current form the paper provides no evidence for representativeness: there is no prototype, no validation on held-out traces, no comparison with existing generators, and no demonstration that generated systems preserve scale, topology, or latency distributions. The significance is therefore potential rather than demonstrated. I credit the authors for clearly formulating the problem and for grounding the design in existing systems such as Blueprint and causal root-cause analysis, but the paper offers no reproducible artifacts and no falsifiable predictions that have been tested.

major comments (5)
  1. [Section 2.3 and Section 3.2] The representativeness claim is asserted rather than tested. Section 2.3 states that "any new sample generated by the GCM will be representative of the original data" solely because the GCM internally uses inferred causal effects from the observed data. This is a fitting-then-resampling procedure, and it is circular without validation on data not used for fitting. The paper provides no experiment in which generated traces or a generated system are compared with the original traces on structural properties (call graph, fan-in/fan-out), execution paths, latency CDFs, or tail quantiles. This validation is load-bearing because the motivation in Section 2.1 explicitly requires preservation of scale, topology, and tail latency.
  2. [Table 2 and Section 3.4] The generative equations in Table 2 specify only conditional means: each latency is a weighted sum (or a max) of parent latencies plus an intercept C, with Bernoulli call indicators, and no noise or residual term is defined anywhere in the paper. Section 3.2 says only that coefficients are fit to observed trace data. Consequently, conditioned on parent values and call indicators, every generated sample of a node's latency is a single point mass; the model has no mechanism to reproduce observed variance, multi-modality, or heavy tails. Leaf nodes are not assigned any generative distribution, so the problem cannot be delegated to the leaves. Since Section 2.1 identifies tail latency (for example, p99) as a key property for research use cases, the described model is structurally incapable of the paper's central representativeness claim as written.
  3. [Sections 3.1-3.4] The paper is design-only: no prototype, deployment, or measurement is reported. There is no end-to-end generated system, no comparison against existing open-source microservice benchmarks such as TrainTicket or DeathStarBench, no comparison against trace replay or other workload generators, and no quantification of scale, generation time, or runtime overhead. For a paper that introduces "Palette, a system that generates representative flexible macrobenchmark microservice systems," the absence of any evaluation is a central omission rather than a presentation issue.
  4. [Figure 1] Figure 1 is presented as motivation, but it only demonstrates that a "simple statistical approach" fails to reproduce the latency distribution of a downstream service; it does not show a generated latency CDF from Palette. The text gives no dataset, no experimental setup, and no precise definition of the baseline. As the only figure in the paper, it cannot support the claim that GCM-based generation preserves representativeness; it only establishes that a strawman fails.
  5. [Section 3.2] The model fitting procedure is underspecified. The paper states that coefficients (the various lambda_a) are fit to observed trace data, but it gives no algorithm for estimating the parameters of the nonlinear equations in Table 2, which include Bernoulli call indicators, weighted sums, and max operations. Identifiability of coefficients in the concurrent (max) case is not discussed, and no procedure is given for estimating the intercept C or for handling missing calls. Without this information, it is impossible to assess whether the claimed model can actually be estimated from real traces.
minor comments (4)
  1. [Abstract and Title] The phrase "macrobenchmark microservice systems" in the title and abstract is grammatically awkward; consider "macrobenchmark microservice systems" or "macrobenchmarks for microservice systems."
  2. [Section 2.3] There is a typo in the sentence "GCMs help preserve the properties of the original system an can generate new samples": "an" should be "and."
  3. [Page header] The manuscript uses the template header "Conference'17, July 2017, Washington, DC, USA," which should be updated for the submission venue.
  4. [Figure 1] Figure 1 would benefit from a description of the dataset, the exact statistical model used as the strawman, and a statement of how many traces or requests were used to compute the CDFs.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Palette's representativeness claim is an unvalidated empirical assertion, not a derivation that reduces to its own inputs.

full rationale

I examined the claimed derivation chain from trace data to GCM to generated system. The central statement, 'any new sample generated by the GCM will be representative of the original data' (Section 2.3), is presented as a property of GCMs, but it is an assertion about generalization, not a conclusion derived from the model equations. The GCM latencies in Table 2 are deterministic functions of parent latencies and Bernoulli call indicators, and Section 3.2 says the coefficients are fitted to observed trace data. However, 'representative' is not defined as 'sampling from the fitted GCM,' so the claim does not reduce to a self-definitional equivalence. There is no equation in the paper that shows generated samples equal observed samples by construction. The absence of held-out validation and the lack of an explicit residual/noise term are real correctness concerns, but they are validation gaps, not circularity. Self-citations such as Blueprint [2], Sifter [21], and Hindsight [37] are engineering dependencies or prior tracing work; they are not invoked as uniqueness theorems or as the sole justification for the representativeness claim. The cited causal-simulation precedents [1, 38] are external works. No load-bearing step in the paper reduces to its own inputs, so the paper is not circular in the sense required by this analysis.

Assumptions & free parameters 4 free parameters · 3 assumptions · 0 invented entities

The central claim rests on several fitted quantities and unvalidated assumptions. The causal equations in Table 2 introduce coefficients and an intercept fit to trace data, and the representativeness of the GCM is asserted rather than demonstrated.

free parameters (4)
  • causal coefficients lambda_a = not reported
    Coefficients in the causal equations (Table 2) are fit to observed trace data to estimate the effect of each parent latency on the child latency.
  • intercept C = not reported
    An additive constant in the sequential, concurrent, and choice latency equations (Table 2) is fit to traces.
  • call probabilities p_a = derived from traces
    Bernoulli probabilities for 'called' nodes are estimated from the frequency of downstream calls in the trace data.
  • PFA transition probabilities = derived from traces
    Probabilities of state transitions in the PFA are estimated from observed execution paths in the traces.
assumptions (3)
  • domain assumption Causal sufficiency: all relevant variables influencing latency are included in the causal graph.
    The GCM assumes no unobserved confounders, and the paper does not discuss hidden variables in Section 3.1.
  • ad hoc to paper The linear causal equations in Table 2 are adequate to model latency behavior.
    Table 2 defines latency as weighted sums or maximums of parent latencies plus a constant, an assumption not justified by data or theory.
  • ad hoc to paper A GCM fitted to observed traces generates samples representative of the original data.
    Stated in Section 2.3 without proof or empirical validation, this is the load-bearing representativeness assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Generating representative macrobenchmark microservice systems from distributed traces with Palette." pith.science (2026). https://pith.science/paper/MLVYAGDV

@misc{pith2026250606448,
  author       = {Pith},
  title        = {Pith review of: Generating representative macrobenchmark microservice systems from distributed traces with Palette},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MLVYAGDV}},
  note         = {Machine review of arXiv:2506.06448}
}
read the original abstract

Microservices are the dominant design for developing cloud systems today. Advancements for microservice need to be evaluated in representative systems, e.g. with matching scale, topology, and execution patterns. Unfortunately in practice, researchers and practitioners alike often do not have access to representative systems. Thus they have to resort to sub-optimal non-representative alternatives, e.g. small and oversimplified synthetic benchmark systems or simulated system models instead. To solve this issue, we propose the use of distributed trace datasets, available from large internet companies, to generate representative microservice systems. To do so, we introduce a novel abstraction of a system topology which uses Graphical Causal Models (GCMs) to model the underlying system by incorporating the branching probabilities, execution order of outgoing calls to every dependency, and execution times. We then incorporate this topology in Palette, a system that generates representative flexible macrobenchmarks microservice systems from distributed traces.

Figures

Figures reproduced from arXiv: 2506.06448 by the authors.

Figure 1
Figure 1. Latency CDF mismatch with simple statistical [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Palette Pipeline 𝑠𝑡𝑎𝑟𝑡 𝐵 𝐶 𝐷||𝐸 𝑓 𝑖𝑛𝑖𝑠ℎ 0.5 0.4 0.1 0.9 0.1 0.8 0.2 1.0 [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Example latency causal graph GCM Captures Performance Properties. A GCM is in￾cluded in the topology structure of each API to encode the performance properties of the observed system. Suppose we want to model the latency of an API, A, which calls two downstream APIs, B and C with differing probabilities. Each API’s latency is represented as a separate node, and the la￾tency of A depends on the latencies of B and C, … view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

42 extracted references · 39 canonical work pages

  1. [1]

    In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 1115–1147, 2023

    Abdullah Alomar, Pouya Hamadanian, Arash Nasr-Esfahany, Anish Agarwal, Mohammad Alizadeh, and Devavrat Shah.{CausalSim}: A causal framework for unbiased{Trace-Driven} simulation. In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 1115–1147, 2023

    work page 2023

  2. [2]

    Blueprint: A toolchain for highly-reconfigurable microservice appli- cations

    Vaastav Anand, Deepak Garg, Antoine Kaufmann, and Jonathan Mace. Blueprint: A toolchain for highly-reconfigurable microservice appli- cations. InProceedings of the 29th Symposium on Operating Systems Principles, pages 482–497, 2023

    work page 2023

  3. [3]

    Why did the distribution change? InInternational Conference on Artificial Intelligence and Statistics, pages 1666–1674

    Kailash Budhathoki, Dominik Janzing, Patrick Bloebaum, and Hoiyi Ng. Why did the distribution change? InInternational Conference on Artificial Intelligence and Statistics, pages 1666–1674. PMLR, 2021

    work page 2021

  4. [4]

    Causal structure-based root cause analysis of outliers

    Kailash Budhathoki, Lenon Minorics, Patrick Blöbaum, and Dominik Janzing. Causal structure-based root cause analysis of outliers. In International conference on machine learning, pages 2357–2369. PMLR, 2022

    work page 2022

  5. [5]

    The evolution of microservices

    Adrian Cockcroft. The evolution of microservices. (April 2016). Retrieved October 2020 from https://www.slideshare.net/ adriancockcroft/evolution-of-microservices-craft-conference, 2016

    work page 2016

  6. [6]

    Microservices workshop: Why, what, and how to get there

    Adrian Cockcroft. Microservices workshop: Why, what, and how to get there. (April 2016). Retrieved October 2020 from https://www.slideshare.net/adriancockcroft/microservices- workshop-craft-conference, 2016

    work page 2016

  7. [7]

    Root cause analysis (rca) of latencies in a microservice architecture

    DoWhy documentation v0.8. Root cause analysis (rca) of latencies in a microservice architecture. https://www.pywhy.org/dowhy/v0.8/ example_notebooks/rca_microservice_architecture.html, 2024. [Ac- cessed 05-06-2025]

    work page 2024

  8. [8]

    A mi- croservice graph generator with production characteristics, 2024

    Fanrong Du, Jiuchen Shi, Quan Chen, Li Li, and Minyi Guo. A mi- croservice graph generator with production characteristics, 2024

    work page 2024

Show all 42 references
  1. [9]

    Graphical causal models

    Felix Elwert. Graphical causal models. InHandbook of causal analysis for social research, pages 245–273. Springer, 2013

    2013

  2. [10]

    {X-Trace}: A pervasive network tracing framework

    Rodrigo Fonseca, George Porter, Randy H Katz, and Scott Shenker. {X-Trace}: A pervasive network tracing framework. In4th USENIX Symposium on Networked Systems Design & Implementation (NSDI 07), 2007

    2007

  3. [11]

    Making kernel bypass practical for the cloud with junction

    Joshua Fried, Gohar Irfan Chaudhry, Enrique Saurez, Esha Choukse, Íñigo Goiri, Sameh Elnikety, Rodrigo Fonseca, and Adam Belay. Making kernel bypass practical for the cloud with junction. In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 5...

    2024

  4. [12]

    An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems

    Yu Gan, Yanqi Zhang, Dailun Cheng, Ankitha Shetty, Priyal Rathi, Nayan Katarki, Ariana Bruno, Justin Hu, Brian Ritchken, Brendon Jackson, et al. An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems. In Proceedings o...

    2019

  5. [13]

    Service-oriented architecture: Scaling the uber engi- neering codebase as we grow

    Einas Haddad. Service-oriented architecture: Scaling the uber engi- neering codebase as we grow. (September 2015). Retrieved October 2020 from https://eng.uber.com/service-oriented-architecture/, 2015

    2015

  6. [14]

    (January 2017)

    Mazdak Hashemi. (January 2017). Retrieved February 2021 from https://blog.twitter.com/engineering/en_us/topics/infrastructure/ 2017/the-infrastructure-behind-twitter-scale.html, 2017

    2017

  7. [15]

    Lifting the veil on {Meta’s} microservice architecture: Analyses of topology and request workflows

    Darby Huye, Yuri Shkuro, and Raja R Sambasivan. Lifting the veil on {Meta’s} microservice architecture: Analyses of topology and request workflows. In2023 USENIX Annual Technical Conference (USENIX ATC 23), pages 419–432, 2023

    2023

  8. [16]

    Causal structure based root cause analysis of outliers.arXiv preprint arXiv:1912.02724, 2019

    Dominik Janzing, Kailash Budhathoki, Lenon Minorics, and Patrick Blöbaum. Causal structure based root cause analysis of outliers.arXiv preprint arXiv:1912.02724, 2019

    1912 arXiv

  9. [17]

    Datacenter RPCs can be general and fast

    Anuj Kalia, Michael Kaminsky, and David Andersen. Datacenter RPCs can be general and fast. In16th USENIX Symposium on Networked Systems Design and Implementation, NSDI, 2019

    2019

  10. [18]

    Sharma, Arvind Krishnamurthy, and Thomas Anderson

    Antoine Kaufmann, Tim Stamler, Simon Peter, Naveen Kr. Sharma, Arvind Krishnamurthy, and Thomas Anderson. TAS: TCP acceleration as an OS service. In14th ACM European Conference on Computer Systems, EuroSys, 2019

    2019

  11. [19]

    R2P2: Making RPCs first-class datacenter citizens

    Marios Kogias, George Prekas, Adrien Ghosn, Jonas Fietz, and Edouard Bugnion. R2P2: Making RPCs first-class datacenter citizens. In2019 USENIX Annual Technical Conference, ATC, 2019

    2019

  12. [20]

    Swift: Delay is simple and effective for congestion control in the datacenter

    Gautam Kumar, Nandita Dukkipati, Keon Jang, Hassan MG Was- sel, Xian Wu, Behnam Montazeri, Yaogong Wang, Kevin Springborn, Christopher Alfeld, Michael Ryan, et al. Swift: Delay is simple and effective for congestion control in the datacenter. InProceedings of the Annual confer...

    2020

  13. [21]

    Sifter: Scalable sampling for distributed traces, without fea- ture engineering

    Pedro Las-Casas, Giorgi Papakerashvili, Vaastav Anand, and Jonathan Mace. Sifter: Scalable sampling for distributed traces, without fea- ture engineering. InProceedings of the ACM Symposium on Cloud Computing, pages 312–324, 2019

    2019

  14. [22]

    The tale of errors in microservices.Proceedings of the ACM on Measurement and Analysis of Computing Systems, 8(3):1–36, 2024

    I-Ting Angelina Lee, Zhizhou Zhang, Abhishek Parwal, and Milind Chabbi. The tale of errors in microservices.Proceedings of the ACM on Measurement and Analysis of Computing Systems, 8(3):1–36, 2024

    2024

  15. [23]

    Characterizing microservice dependency and performance: Alibaba trace analysis

    Shutian Luo, Huanle Xu, Chengzhi Lu, Kejiang Ye, Guoyao Xu, Lip- ing Zhang, Yu Ding, Jian He, and Chengzhong Xu. Characterizing microservice dependency and performance: Alibaba trace analysis. InProceedings of the ACM Symposium on Cloud Computing, pages 412–426, 2021

    2021

  16. [24]

    Universal context propagation for distributed system instrumentation

    Jonathan Mace and Rodrigo Fonseca. Universal context propagation for distributed system instrumentation. InProceedings of the thirteenth EuroSys conference, pages 1–18, 2018

    2018

  17. [25]

    Sockshop

    microservices demo. Sockshop. Retrieved August 2022 from https: //github.com/microservices-demo/microservices-demo, 2016

    2022

  18. [26]

    In14th USENIX symposium on operating systems design and implementation (OSDI 20), pages 805–825, 2020

    Haoran Qiu, Subho S Banerjee, Saurabh Jha, Zbigniew T Kalbarczyk, and Ravishankar K Iyer.{FIRM}: An intelligent fine-grained resource management framework for{SLO-Oriented} microservices. In14th USENIX symposium on operating systems design and implementation (OSDI 20), pages 8...

    2020

  19. [27]

    Traceupscaler: Upscaling traces to evaluate systems at high load

    Sultan Mahmud Sajal, Timothy Zhu, Bhuvan Urgaonkar, and Sid- dhartha Sen. Traceupscaler: Upscaling traces to evaluate systems at high load. InProceedings of the Nineteenth European Conference on Computer Systems, pages 942–961, 2024

    2024

  20. [28]

    A cloud-scale characteri- zation of remote procedure calls

    Korakit Seemakhupt, Brent E Stephens, Samira Khan, Sihang Liu, Has- san Wassel, Soheil Hassas Yeganeh, Alex C Snoeren, Arvind Krishna- murthy, David E Culler, and Henry M Levy. A cloud-scale characteri- zation of remote procedure calls. InProceedings of the 29th Symposium on O...

    2023

  21. [29]

    [sok] identifying mismatches between microservice testbeds and industrial perceptions of microservices.Journal of Systems Research, 2(1), 2022

    Vishwanath Seshagiri, Darby Huye, Lan Liu, Avani Wildani, and Raja R Sambasivan. [sok] identifying mismatches between microservice testbeds and industrial perceptions of microservices.Journal of Systems Research, 2(1), 2022

    2022

  22. [30]

    In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 1101–1120, 2024

    Gagan Somashekar, Karan Tandon, Anush Kini, Chieh-Chun Chang, Petr Husak, Ranjita Bhagwan, Mayukh Das, Anshul Gandhi, and Na- garajan Natarajan.{OPPerTune}:{Post-Deployment} configuration tuning of services made easy. In21st USENIX Symposium on Networked Systems Design and Imp...

    2024

  23. [31]

    Soft- sku: Optimizing server architectures for microservice diversity@ scale

    Akshitha Sriraman, Abhishek Dhanotia, and Thomas F Wenisch. Soft- sku: Optimizing server architectures for microservice diversity@ scale. InProceedings of the 46th International Symposium on Computer Archi- tecture, pages 513–526, 2019

    2019

  24. [32]

    In13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 177–194, 2018

    Akshitha Sriraman and Thomas F Wenisch.{𝜇 Tune}:{Auto-Tuned} threading for{OLDI} microservices. In13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 177–194, 2018

    2018

  25. [33]

    Automating instrumentation choices for performance problems in dis- tributed applications with vaif

    Mert Toslali, Emre Ates, Alex Ellis, Zhaoqi Zhang, Darby Huye, Lan Liu, Samantha Puterman, Ayse K Coskun, and Raja R Sambasivan. Automating instrumentation choices for performance problems in dis- tributed applications with vaif. InProceedings of the ACM Symposium on Cloud Com...

    2021

  26. [34]

    Cloud atlas: Efficient fault localization for cloud systems using language models and causal insight.arXiv preprint arXiv:2407.08694, 2024

    Zhiqiang Xie, Yujia Zheng, Lizi Ottens, Kun Zhang, Christos Kozyrakis, and Jonathan Mace. Cloud atlas: Efficient fault localization for cloud systems using language models and causal insight.arXiv preprint arXiv:2407.08694, 2024

    2024 arXiv

  27. [35]

    In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 221– 238, 2024

    Haoran Zhang, Konstantinos Kallas, Spyros Pavlatos, Rajeev Alur, Sebastian Angel, and Vincent Liu.{MuCache}: A general framework for caching in microservice graphs. In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24), pages 221– 238, 2024

    2024

  28. [36]

    The demikernel datapath os architecture for microsecond-scale datacenter systems

    Irene Zhang, Amanda Raybuck, Pratyush Patel, Kirk Olynyk, Jacob Nelson, Omar S Navarro Leija, Ashlie Martinez, Jing Liu, Anna Ko- rnfeld Simpson, Sujay Jayakar, et al. The demikernel datapath os architecture for microsecond-scale datacenter systems. InProceedings of the ACM SI...

    2021

  29. [37]

    The benefit of hindsight: Tracing{Edge-Cases} in distributed systems

    Lei Zhang, Zhiqiang Xie, Vaastav Anand, Ymir Vigfusson, and Jonathan Mace. The benefit of hindsight: Tracing{Edge-Cases} in distributed systems. In20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 321–339, 2023

    2023

  30. [38]

    Latenseer: Causal modeling of end-to-end latency distributions by harnessing distributed tracing

    Yazhuo Zhang, Rebecca Isaacs, Yao Yue, Juncheng Yang, Lei Zhang, and Ymir Vigfusson. Latenseer: Causal modeling of end-to-end latency distributions by harnessing distributed tracing. InProceedings of the 2023 ACM Symposium on Cloud Computing, pages 502–519, 2023

    2023

  31. [39]

    {CRISP}: Critical path analysis of{Large-Scale} microservice architectures

    Zhizhou Zhang, Murali Krishna Ramanathan, Prithvi Raj, Abhishek Parwal, Timothy Sherwood, and Milind Chabbi. {CRISP}: Critical path analysis of{Large-Scale} microservice architectures. In2022 USENIX Annual Technical Conference (USENIX ATC 22), pages 655–672, 2022

    2022

  32. [40]

    Chase: A causal hypergraph based framework for root cause analysis in mul- timodal microservice systems, 2025

    Ziming Zhao, Zhenwei Wang, Tiehua Zhang, Zhishu Shen, Hai Dong, Zhen Lei, Xingjun Ma, Gaowei Xu, Zhijun Ding, and Yun Yang. Chase: A causal hypergraph based framework for root cause analysis in mul- timodal microservice systems, 2025

    2025

  33. [41]

    Fasttune: Timely and precise congestion control in data center network

    Renjie Zhou, Dezun Dong, Shan Huang, and Yang Bai. Fasttune: Timely and precise congestion control in data center network. In2021 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Big Data & Cloud Computing, Sustainable Computing & Communications, So- cial...

    2021

  34. [42]

    Poster: Benchmarking microservice systems for soft- ware engineering research

    Xiang Zhou, Xin Peng, Tao Xie, Jun Sun, Chenjie Xu, Chao Ji, and Wenyun Zhao. Poster: Benchmarking microservice systems for soft- ware engineering research. In2018 IEEE/ACM 40th International Con- ference on Software Engineering: Companion (ICSE-Companion), pages 323–324. IEEE, 2018

    2018

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.