diff options
author | gVisor bot <gvisor-bot@google.com> | 2020-09-24 15:33:05 -0700 |
---|---|---|
committer | gVisor bot <gvisor-bot@google.com> | 2020-09-24 15:33:05 -0700 |
commit | 74870fc203e373d8258dfb6cb1fa0f78cb090062 (patch) | |
tree | 155e1636166c9b2e9d93053604450b8f615b335d | |
parent | ada4d8a33724f6888049795832067a5e4c771cc8 (diff) | |
parent | be86a915844ead7965afd1379e95ed680166e85f (diff) |
Merge pull request #4018 from didier-durand:patch-1
PiperOrigin-RevId: 333611788
-rw-r--r-- | g3doc/architecture_guide/performance.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/g3doc/architecture_guide/performance.md b/g3doc/architecture_guide/performance.md index 39dbb0045..b981f0c01 100644 --- a/g3doc/architecture_guide/performance.md +++ b/g3doc/architecture_guide/performance.md @@ -30,7 +30,7 @@ is distinct from **structural costs**. Improvements here are ongoing and driven by the workloads that matter to gVisor users and contributors. This page provides a guide for understanding baseline performance, and calls out -distint **structural costs** and **implementation costs**, highlighting where +distinct **structural costs** and **implementation costs**, highlighting where improvements are possible and not possible. While we include a variety of workloads here, it’s worth emphasizing that gVisor @@ -211,7 +211,7 @@ url="/performance/applications.csv" title="perf.py http.(node|ruby) The above figure shows the result of simple `node` and `ruby` web services that render a template upon receiving a request. Because these synthetic benchmarks -do minimal work per request, must like the `redis` case, they suffer from high +do minimal work per request, much like the `redis` case, they suffer from high overheads. In practice, the more work an application does the smaller the impact of **structural costs** become. |