用自己的时间测量延迟开销

A new metric to quantify the latency overhead of our Viaduct framework

一个新的指标来量化我们的Viaduct框架的延迟开销

Viaduct, a GraphQL-based data-oriented service mesh, is Airbnb’s paved road solution for fetching internal data and serving public-facing API requests. As a unified data access layer, the Viaduct framework handles high throughput and is capable of dynamically routing to hundreds of downstream destinations when executing arbitrary GraphQL queries.

Viaduct是一个基于GraphQL的面向数据的服务网，是Airbnb为获取内部数据和服务面向公众的API请求而铺设的道路解决方案。作为一个统一的数据访问层，Viaduct框架可以处理高吞吐量，并能够在执行任意的GraphQL查询时动态路由到数百个下游目的地。

Performance Challenges in Viaduct

高架桥的性能挑战

Viaduct’s role as a data access layer puts it in the critical path of most activity on Airbnb. This makes runtime performance of utmost importance as overhead in the framework will apply universally and can have a multiplicative effect. At the same time, Viaduct accepts arbitrary queries against the unified data graph. In practice, this amounts to many thousands of heterogeneous queries in production, each of which is capable of making an arbitrary number of downstream and often concurrent calls during the course of query execution.

Viaduct作为数据访问层的角色使它处于Airbnb上大多数活动的关键路径上。这使得运行时的性能变得极为重要，因为框架中的开销将普遍适用，并可能产生倍增效应。同时，Viaduct接受对统一数据图的任意查询。在实践中，这相当于生产中成千上万的异质查询，每个查询都能够在查询执行过程中进行任意数量的下游调用，而且往往是并发的。

This presented a challenge for us. Runtime overhead in Viaduct is crucial for us to monitor and improve, but we did not have a good measure for it. Metrics on end-to-end query latencies are confounded by the performance of downstream services, making it difficult to accurately judge the effect of a performance intervention in Viaduct. We needed a metric that isolates the performance impact of Viaduct changes from the performance impact of downstream services.

这对我们来说是一个挑战。Viaduct的运行时间开销对我们的监控和改进至关重要，但我们没有一个好的衡量标准。端到端查询延迟的指标被下游服务的性能所干扰，这使得我们很难准确判断Viaduct的性能干预的效果。我们需要一个指标，将Viaduct变化的性能影响与下游服务的性能影响隔离开来。

Defining Own Time

界定自己的时间

To do this, we created a metric called “own time”. Own time ...