summaryrefslogtreecommitdiffhomepage
path: root/g3doc
diff options
context:
space:
mode:
authorgVisor bot <gvisor-bot@google.com>2020-09-24 15:33:05 -0700
committergVisor bot <gvisor-bot@google.com>2020-09-24 15:33:05 -0700
commit74870fc203e373d8258dfb6cb1fa0f78cb090062 (patch)
tree155e1636166c9b2e9d93053604450b8f615b335d /g3doc
parentada4d8a33724f6888049795832067a5e4c771cc8 (diff)
parentbe86a915844ead7965afd1379e95ed680166e85f (diff)
Merge pull request #4018 from didier-durand:patch-1
PiperOrigin-RevId: 333611788
Diffstat (limited to 'g3doc')
-rw-r--r--g3doc/architecture_guide/performance.md4
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.