Сервис Docker плохая производительность сети

Question

У меня есть сервис go (http.ListenAndServe), который просто повторяет «hello world» (самый базовый сервис, чтобы не вносить издержки в тестирование). Вопрос в том, что если я запускаю службу с помощью go run server.go и запускаю тест производительности (используя wrk https://github.com/wg/wrk) на моей локальной машине (Macbook pro), я получаю производительность

Requests/sec: 59336.07
Transfer/sec: 8.66MiB

но если я просто запустил службу в docker (docker run -p8080: 8080 periket2000 / goku) и снова запустил тест производительности, я получил:

Requests/sec: 4743.77
Transfer/sec: 0.69MiB

Имеет ли это смысл? Это докер так плохо работает? Я протестировал его с несколькими службами / стеками и получил те же результаты.

Answer 1

Служба, которую вы описываете, делает очень мало, и, глядя на ее страницу GitHub, она выглядит так, как будто wrk делает все возможное, чтобы избежать таких вещей, как постоянные соединения HTTP, поэтому ваш тест в основном только проверяет, насколько быстро может работать объединенная система. и разорвать TCP-соединения. Обратите внимание, что скорость передачи данных, даже в случае обратной петли, действительно низкая: требуется много рукопожатий, накладных расходов IP и TCP и HTTP-заголовков, прежде чем вы скажете «привет мир» и повесьте трубку.

В случае обратной петли весьма вероятно, что ядро ​​MacOS может передавать данные практически напрямую из одного процесса в другой.

Process A |--> Local loopback ----> | Process B

В случае с Docker трафик должен проходить через виртуальный сетевой интерфейс, в виртуальную машину, получать его через сетевой интерфейс ядра Linux, проходить уровень NAT в пространство Docker, а затем получать процесс; ответы должны пройти через этот стек в обратном порядке. Неудивительно, что это приводит к дополнительным издержкам, а крошечные пакеты делают его еще хуже (см. Обсуждение установления соединения на странице Википедии по TCP ; там каждая сторона ожидает завершения SYN-ACK и Последовательности FIN-RST и те, которые не несут данных IIRC). Итак, эти результаты не удивительны.

Process A |--> Virtual interface
               Linux VM eth0
               iptables NAT
               Linux VM docker0
               Container eth0 ----> | Process B

В абсолютных числах в системах, с которыми я работал в прошлом, получение более 4000 запросов в секунду определенно попадает в область «респектабельной производительности». (Скорость передачи данных только 8 МБ / с с обратной связью не выглядит звездной из-за характера рабочей нагрузки.) Возможно, стоит повторить тест с более реалистичной рабочей нагрузкой (смесь GET и POST; нетривиально ответы на данные; некоторые вычисления или внешние операции ввода-вывода, необходимые для получения результатов). Я бы не ожидал, что Docker для Mac достигнет 100% производительности чисто нативной настройки без внешней сети, но я бы ожидал, что в этом случае помогут более высокие соотношения данных и служебных данных, например постоянные соединения HTTP.