Remove superfluous redirects
This commit is contained in:
Ian Lewis
Ian Lewis
parent
7f75f52403
commit
46ee8873ff
|
|
@ -7,7 +7,7 @@ description = "A container sandbox runtime focused on security, efficiency, and
|
|||
{{< blocks/cover image_anchor="top" height="auto" color="primary" title="gVisor" >}}
|
||||
<div class="mx-auto">
|
||||
<p class="lead">A container sandbox runtime focused on <strong>security</strong>, <strong>efficiency</strong>, and <strong>ease of use</strong>.</p>
|
||||
<a class="btn btn-lg btn-primary mr-3 mb-4" href="./docs/user_guide/docker/" >Quick Start<i class="fas fa-arrow-alt-circle-right ml-2"></i></a>
|
||||
<a class="btn btn-lg btn-primary mr-3 mb-4" href="./docs/user_guide/docker/">Quick Start<i class="fas fa-arrow-alt-circle-right ml-2"></i></a>
|
||||
<a class="btn btn-lg btn-secondary mr-3 mb-4" href="https://github.com/google/gvisor" rel="noopener">GitHub <i class="fab fa-github ml-2"></i></a>
|
||||
</div>
|
||||
{{< /blocks/cover >}}
|
||||
|
|
@ -41,7 +41,7 @@ Read the [documentation](./docs/) to understand gVisor, its architecture and tra
|
|||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature icon="fas fa-code-branch" title="Contribute to gVisor" %}}
|
||||
Anyone is welcome to be a gVisor contributor. Please check out the [community information](./docs/community) to get started.
|
||||
Anyone is welcome to be a gVisor contributor. Please check out the [community information](./docs/community/) to get started.
|
||||
{{% /blocks/feature %}}
|
||||
|
||||
{{% blocks/feature icon="fab fa-github" title="Give Feedback" %}}
|
||||
|
|
|
|||
|
|
@ -2,6 +2,7 @@
|
|||
title = "Performance Guide"
|
||||
weight = 30
|
||||
+++
|
||||
|
||||
gVisor is designed to provide a secure, virtualized environment while preserving
|
||||
key benefits of containerization, such as small fixed overheads and a dynamic
|
||||
resource footprint. For containerized infrastructure, this can provide a
|
||||
|
|
@ -35,7 +36,7 @@ improvements are possible and not possible.
|
|||
While we include a variety of workloads here, it’s worth emphasizing that gVisor
|
||||
may not be an appropriate solution for every workload, for reasons other than
|
||||
performance. For example, a sandbox may provide minimal benefit for a trusted
|
||||
database, since *user data would already be inside the sandbox* and there is no
|
||||
database, since _user data would already be inside the sandbox_ and there is no
|
||||
need for an attacker to break out in the first place.
|
||||
|
||||
## Methodology
|
||||
|
|
@ -44,11 +45,9 @@ All data below was generated using the [benchmark tools][benchmark-tools]
|
|||
repository, and the machines under test are uniform [Google Compute Engine][gce]
|
||||
Virtual Machines (VMs) with the following specifications:
|
||||
|
||||
```
|
||||
Machine type: n1-standard-4 (broadwell)
|
||||
Image: Debian GNU/Linux 9 (stretch) 4.19.0-0
|
||||
BootDisk: 2048GB SSD persistent disk
|
||||
```
|
||||
Machine type: n1-standard-4 (broadwell)
|
||||
Image: Debian GNU/Linux 9 (stretch) 4.19.0-0
|
||||
BootDisk: 2048GB SSD persistent disk
|
||||
|
||||
Through this document, `runsc` is used to indicate the runtime provided by
|
||||
gVisor. When relevant, we use the name `runsc-platform` to describe a specific
|
||||
|
|
@ -69,7 +68,7 @@ accesses. Page faults and other Operating System (OS) mechanisms are translated
|
|||
through the Sentry, but once mappings are installed and available to the
|
||||
application, there is no additional overhead.
|
||||
|
||||
{{< graph id="sysbench-memory" url="/performance/sysbench-memory.csv" title="perf.py sysbench.memory --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="sysbench-memory" url="/performance/sysbench-memory.csv" title="perf.py sysbench.memory --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
The above figure demonstrates the memory transfer rate as measured by
|
||||
`sysbench`.
|
||||
|
|
@ -85,7 +84,7 @@ For many use cases, fixed memory overheads are a primary concern. This may be
|
|||
because sandboxed containers handle a low volume of requests, and it is
|
||||
therefore important to achieve high densities for efficiency.
|
||||
|
||||
{{< graph id="density" url="/performance/density.csv" title="perf.py density --runtime=runc --runtime=runsc" log="true" y_min="100000" >}}
|
||||
{{< graph id="density" url="/performance/density.csv" title="perf.py density --runtime=runc --runtime=runsc" log="true" y_min="100000" >}}
|
||||
|
||||
The above figure demonstrates these costs based on three sample applications.
|
||||
This test is the result of running many instances of a container (50, or 5 in
|
||||
|
|
@ -108,7 +107,7 @@ gVisor does not perform emulation or otherwise interfere with the raw execution
|
|||
of CPU instructions by the application. Therefore, there is no runtime cost
|
||||
imposed for CPU operations.
|
||||
|
||||
{{< graph id="sysbench-cpu" url="/performance/sysbench-cpu.csv" title="perf.py sysbench.cpu --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="sysbench-cpu" url="/performance/sysbench-cpu.csv" title="perf.py sysbench.cpu --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
The above figure demonstrates the `sysbench` measurement of CPU events per
|
||||
second. Events per second is based on a CPU-bound loop that calculates all prime
|
||||
|
|
@ -119,7 +118,7 @@ This has important consequences for classes of workloads that are often
|
|||
CPU-bound, such as data processing or machine learning. In these cases, `runsc`
|
||||
will similarly impose minimal runtime overhead.
|
||||
|
||||
{{< graph id="tensorflow" url="/performance/tensorflow.csv" title="perf.py tensorflow --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="tensorflow" url="/performance/tensorflow.csv" title="perf.py tensorflow --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
For example, the above figure shows a sample TensorFlow workload, the
|
||||
[convolutional neural network example][cnn]. The time indicated includes the
|
||||
|
|
@ -133,7 +132,7 @@ supports a variety of platforms. These platforms present distinct performance,
|
|||
compatibility and security trade-offs. For example, the KVM platform has low
|
||||
overhead system call interception but runs poorly with nested virtualization.
|
||||
|
||||
{{< graph id="syscall" url="/performance/syscall.csv" title="perf.py syscall --runtime=runc --runtime=runsc-ptrace --runtime=runsc-kvm" y_min="100" log="true" >}}
|
||||
{{< graph id="syscall" url="/performance/syscall.csv" title="perf.py syscall --runtime=runc --runtime=runsc-ptrace --runtime=runsc-kvm" y_min="100" log="true" >}}
|
||||
|
||||
The above figure demonstrates the time required for a raw system call on various
|
||||
platforms. The test is implemented by a custom binary which performs a large
|
||||
|
|
@ -144,7 +143,7 @@ tend to be high-performance data stores and static network services. In general,
|
|||
the impact of system call interception will be lower the more work an
|
||||
application does.
|
||||
|
||||
{{< graph id="redis" url="/performance/redis.csv" title="perf.py redis --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="redis" url="/performance/redis.csv" title="perf.py redis --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
For example, `redis` is an application that performs relatively little work in
|
||||
userspace: in general it reads from a connected socket, reads or modifies some
|
||||
|
|
@ -164,7 +163,7 @@ For many use cases, the ability to spin-up containers quickly and efficiently is
|
|||
important. A sandbox may be short-lived and perform minimal user work (e.g. a
|
||||
function invocation).
|
||||
|
||||
{{< graph id="startup" url="/performance/startup.csv" title="perf.py startup --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="startup" url="/performance/startup.csv" title="perf.py startup --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
The above figure indicates how total time required to start a container through
|
||||
[Docker][docker]. This benchmark uses three different applications. First, an
|
||||
|
|
@ -176,7 +175,7 @@ similarly loads a number of modules and binds an HTTP server.
|
|||
> Note: most of the time overhead above is associated Docker itself. This is
|
||||
> evident with the empty `runc` benchmark. To avoid these costs with `runsc`,
|
||||
> you may also consider using `runsc do` mode or invoking the [OCI
|
||||
> runtime](../../user_guide/oci) directly.
|
||||
> runtime](../../user_guide/oci/) directly.
|
||||
|
||||
## Network
|
||||
|
||||
|
|
@ -187,14 +186,14 @@ While typically not an important metric in practice for common sandbox use
|
|||
cases, nevertheless `iperf` is a common microbenchmark used to measure raw
|
||||
throughput.
|
||||
|
||||
{{< graph id="iperf" url="/performance/iperf.csv" title="perf.py iperf --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="iperf" url="/performance/iperf.csv" title="perf.py iperf --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
The above figure shows the result of an `iperf` test between two instances. For
|
||||
the upload case, the specified runtime is used for the `iperf` client, and in
|
||||
the download case, the specified runtime is the server. A native runtime is
|
||||
always used for the other endpoint in the test.
|
||||
|
||||
{{< graph id="applications" metric="requests_per_second" url="/performance/applications.csv" title="perf.py http.(node|ruby) --connections=25 --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="applications" metric="requests_per_second" url="/performance/applications.csv" title="perf.py http.(node|ruby) --connections=25 --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
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
|
||||
|
|
@ -215,20 +214,20 @@ through the [Gofer](../) as a result of our [security model](../security/), but
|
|||
in most cases are dominated by **implementation costs**, due to an internal
|
||||
[Virtual File System][vfs] (VFS) implementation that needs improvement.
|
||||
|
||||
{{< graph id="fio-bw" url="/performance/fio.csv" title="perf.py fio --engine=sync --runtime=runc --runtime=runsc" log="true" >}}
|
||||
{{< graph id="fio-bw" url="/performance/fio.csv" title="perf.py fio --engine=sync --runtime=runc --runtime=runsc" log="true" >}}
|
||||
|
||||
The above figures demonstrate the results of `fio` for reads and writes to and
|
||||
from the disk. In this case, the disk quickly becomes the bottleneck and
|
||||
dominates other costs.
|
||||
|
||||
{{< graph id="fio-tmpfs-bw" url="/performance/fio-tmpfs.csv" title="perf.py fio --engine=sync --runtime=runc --tmpfs=True --runtime=runsc" log="true" >}}
|
||||
{{< graph id="fio-tmpfs-bw" url="/performance/fio-tmpfs.csv" title="perf.py fio --engine=sync --runtime=runc --tmpfs=True --runtime=runsc" log="true" >}}
|
||||
|
||||
The above figure shows the raw I/O performance of using a `tmpfs` mount which is
|
||||
sandbox-internal in the case of `runsc`. Generally these operations are
|
||||
similarly bound to the cost of copying around data in-memory, and we don't see
|
||||
the cost of VFS operations.
|
||||
|
||||
{{< graph id="httpd100k" metric="transfer_rate" url="/performance/httpd100k.csv" title="perf.py http.httpd --connections=1 --connections=5 --connections=10 --connections=25 --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="httpd100k" metric="transfer_rate" url="/performance/httpd100k.csv" title="perf.py http.httpd --connections=1 --connections=5 --connections=10 --connections=25 --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
The high costs of VFS operations can manifest in benchmarks that execute many
|
||||
such operations in the hot path for serving requests, for example. The above
|
||||
|
|
@ -241,16 +240,22 @@ internal serialization points (since all requests are reading the same file).
|
|||
Note that some of some of network stack performance issues also impact this
|
||||
benchmark.
|
||||
|
||||
{{< graph id="ffmpeg" url="/performance/ffmpeg.csv" title="perf.py media.ffmpeg --runtime=runc --runtime=runsc" >}}
|
||||
{{< graph id="ffmpeg" url="/performance/ffmpeg.csv" title="perf.py media.ffmpeg --runtime=runc --runtime=runsc" >}}
|
||||
|
||||
For benchmarks that are bound by raw disk I/O and a mix of compute, file system
|
||||
operations are less of an issue. The above figure shows the total time required
|
||||
for an `ffmpeg` container to start, load and transcode a 27MB input video.
|
||||
|
||||
[ab]: https://en.wikipedia.org/wiki/ApacheBench
|
||||
|
||||
[benchmark-tools]: https://gvisor.googlesource.com/benchmark-tools
|
||||
|
||||
[gce]: https://cloud.google.com/compute/
|
||||
|
||||
[cnn]: https://github.com/aymericdamien/TensorFlow-Examples/blob/master/examples/3_NeuralNetworks/convolutional_network.py
|
||||
|
||||
[docker]: https://docker.io
|
||||
|
||||
[redis-benchmark]: https://redis.io/topics/benchmarks
|
||||
|
||||
[vfs]: https://en.wikipedia.org/wiki/Virtual_file_system
|
||||
|
|
|
|||
Loading…
Reference in New Issue