performance - implementar - ¿Cuál es el costo de rendimiento en tiempo de ejecución de un contenedor Docker?

implementar docker (3)

Me gustaría comprender de manera integral el costo de rendimiento en tiempo de ejecución de un contenedor Docker. He encontrado referencias a redes anecdóticamente siendo ~ 100µs más lentas .

También encontré referencias al costo en tiempo de ejecución como "insignificante" y "cerca de cero", pero me gustaría saber con más precisión cuáles son esos costos. Idealmente, me gustaría saber qué está abstrayendo Docker con un costo de rendimiento y las cosas que se resumen sin un costo de rendimiento. Redes, CPU, memoria, etc.

Además, si hay costos de extracción, hay formas de evitar el costo de extracción. Por ejemplo, tal vez pueda montar un disco directamente vs. virtualmente en Docker.

Aquí hay algunos benchmarks de benchmarks más para el Docker based memcached server versus el Docker based memcached server host native memcached server utilizando la herramienta de punto de referencia Twemperf https://github.com/twitter/twemperf con 5000 conexiones y una velocidad de conexión de 20k

La sobrecarga de tiempo de conexión para memcached basado en ventana acoplable parece concordar con el documento técnico anterior a aproximadamente dos veces la velocidad nativa.

Twemperf Docker Memcached

Connection rate: 9817.9 conn/s Connection time [ms]: avg 341.1 min 73.7 max 396.2 stddev 52.11 Connect time [ms]: avg 55.0 min 1.1 max 103.1 stddev 28.14 Request rate: 83942.7 req/s (0.0 ms/req) Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00 Response rate: 83942.7 rsp/s (0.0 ms/rsp) Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00 Response time [ms]: avg 28.6 min 1.2 max 65.0 stddev 0.01 Response time [ms]: p25 24.0 p50 27.0 p75 29.0 Response time [ms]: p95 58.0 p99 62.0 p999 65.0

Twemperf Centmin Mod Memcached

Connection rate: 11419.3 conn/s Connection time [ms]: avg 200.5 min 0.6 max 263.2 stddev 73.85 Connect time [ms]: avg 26.2 min 0.0 max 53.5 stddev 14.59 Request rate: 114192.6 req/s (0.0 ms/req) Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00 Response rate: 114192.6 rsp/s (0.0 ms/rsp) Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00 Response time [ms]: avg 17.4 min 0.0 max 28.8 stddev 0.01 Response time [ms]: p25 12.0 p50 20.0 p75 23.0 Response time [ms]: p95 28.0 p99 28.0 p999 29.0

Aquí hay bencmarks usando la herramienta de referencia memtier

memtier_benchmark docker Memcached

4 Threads 50 Connections per thread 10000 Requests per thread Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------ Sets 16821.99 --- --- 1.12600 2271.79 Gets 168035.07 159636.00 8399.07 1.12000 23884.00 Totals 184857.06 159636.00 8399.07 1.12100 26155.79

memtier_benchmark Centmin Mod Memcached

4 Threads 50 Connections per thread 10000 Requests per thread Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------ Sets 28468.13 --- --- 0.62300 3844.59 Gets 284368.51 266547.14 17821.36 0.62200 39964.31 Totals 312836.64 266547.14 17821.36 0.62200 43808.90

Docker no es virtualización, como tal, sino que es una abstracción sobre el soporte del kernel para diferentes espacios de nombres de procesos, espacios de nombres de dispositivos, etc .; un espacio de nombres no es intrínsecamente más caro o ineficiente que otro, por lo que lo que realmente hace que Docker tenga un impacto en el rendimiento es una cuestión de lo que realmente hay en esos espacios de nombres.

Las opciones de Docker en términos de cómo configura los espacios de nombres para sus contenedores tienen costos, pero esos costos están directamente asociados con los beneficios; puede renunciar a ellos, pero al hacerlo, también renuncia al beneficio asociado:

Los sistemas de archivos en capas son caros: exactamente los costos varían con cada uno (y Docker admite varios backends), y con sus patrones de uso (fusionar varios directorios grandes, o combinar un conjunto muy profundo de sistemas de archivos será particularmente costoso), pero no eres libre Por otro lado, una gran parte de la funcionalidad de Docker, que puede hacer que los invitados se conviertan en invitados copiados en una escritura, y obtener las ventajas de almacenamiento implícitas en el mismo, depende de pagar este costo.
DNAT es caro a escala, pero le brinda la ventaja de poder configurar la red de su huésped independientemente de la de su host y tener una interfaz conveniente para reenviar solo los puertos que desee entre ellos. Puede reemplazar esto con un puente a una interfaz física, pero nuevamente, pierda el beneficio.
Poder ejecutar cada pila de software con sus dependencias instaladas de la manera más conveniente, independientemente de la distro del host, libc y otras versiones de la biblioteca, es un gran beneficio, pero la necesidad de cargar las bibliotecas compartidas más de una vez (cuando sus versiones diferir) tiene el costo que usted esperaría.

Etcétera. La cantidad de estos costos que realmente lo impactan en su entorno (con sus patrones de acceso a la red, sus limitaciones de memoria, etc.) es un elemento para el cual es difícil proporcionar una respuesta genérica.

Here hay un excelente trabajo de investigación de IBM en 2014 titulado "Una comparación de rendimiento actualizada de máquinas virtuales y contenedores de Linux" por Felter et al. que proporciona una comparación entre contenedores de metal desnudo, KVM y Docker. El resultado general es que Docker es casi idéntico al rendimiento nativo y más rápido que KVM en todas las categorías.

La excepción a esto es el NAT de Docker: si usa la asignación de puertos (por ejemplo, la docker run -p 8080:8080 ), puede esperar un impacto menor en la latencia, como se muestra a continuación. Sin embargo, ahora puede usar la pila de red del host (por ejemplo, la docker run --net=host ) al iniciar un contenedor de Docker, que se realizará de manera idéntica a la columna Native (como se muestra en los resultados de latencia Redis más abajo).

También realizaron pruebas de latencia en algunos servicios específicos, como Redis. Puede ver que por encima de 20 hilos de clientes, la sobrecarga de latencia más alta va a Docker NAT, luego a KVM, y luego a un empate aproximado entre Docker host / native.

Solo porque es un documento realmente útil, aquí hay algunas otras figuras. Por favor descárguelo para tener acceso completo.

Echando un vistazo a Disk IO:

Ahora mirando a la sobrecarga de la CPU:

Ahora algunos ejemplos de memoria (lea el documento para obtener más información, la memoria puede ser muy complicada)