Docker vs Bare Metal — сравнение производительности?

Question

[Антон В.]

Добрый день.

Есть такой набор сервисов, которые между собой общаются.

Nginx
PHP-FPM
Mysql
Laravel-echo-server (node) - websocket
Redis

Для разработки давно используется docker-compose.
Но вот есть сомнения, в том что бы использовать докер в продакшене, который Bare Metal (core 12 ram 64 ssd 512gb). Желание использовать докер в продакшене, возникло во время переезда на другую машину.

Есть ощущение, что общение между контейнерами и внешним миром, будет медленнее, чем на чистом железе.
В гугле читаю противоречивые комментарии.
Например как повлияет общение php к mysql при запросах, будет ли разница...
при обращении nginx к рhp сокету... обращение php к redis...

Может быть, кто то имел опыт, подскажите пожалуйста, как с производительностью и какие есть подводные камни?

Comments

[Антон В.]

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

В связи с этим хочется понять, в описанном стеке на одном хосте, какова будет разница в скорости под нагрузкой.

Мне не хватает глубокого понимания взаимодействия конейнеров в докере, что бы самому это прикинуть.

Поэтому хотелось бы узнать у профи, приблизительно, какой процент берет на себе докер при взаимодействии контейнеров. если сравнивать с сервисами на чистым железом.

С одной стороны есть ощущение, что это должен быть мизер на уровне 2-5%
а другой стороны есть опасение что это разница будет 15-20%

так вот если бы это было 2-5% то конечно выбора за докером.
но если цифры 10-20% то субъективно это дорого, и есть смысл по играться с железом, дописать скрипт развертывания на чистом железе.

Answer 1

[Дмитрий]

Конечно будет тратится какое то количество ресурсов на контейнеризацию. Но в 99% из 100% удобство разработки это перекроет - машинное время стоит копейки, время разработчика наоборот дорого.

IBM Research Report. An Updated Performance Compar...

Comments

[Антон В.]

Спасибо большое за ответ!
И за статью отдельное спасибо! Меня прям восхищают такие работы...

Согласен на счет ценности времени разработчика! Это была одна из причин, по которым вопрос появился.

Можете пожалуйста поделится вашим понимаем, какова примерная потеря при обращении на одном хосте разных контейнеров, например php контейнера к mysql контейнеру.
Скажем скрипт выполнит около сотни запросов к базе. Можно ли сказать что разница в суммарной скорости будет +- одинаковой (если сравнивать с докером и без него). или же потери будут ощутимыми.

[Дмитрий]

Антон В., плюс минус одинаковый. накладные расходы мизерные. Я думаю если у вас нет высоких нагрузок - вы вообще можете не париться насчет накладных расходов на docker.
Но - я не девопс. :)

[Антон В.]

Дмитрий, спасибо большое что поделились вашим мнением!

[DevMan]

эмм... и чем докер добавляет удобство разработки?

для нубов которые тупо следуют инструкции - да.
для людей с правильным радиусом рук, он нахрен не нужен.

докер хорошь для продакшена, не для дева.

[Дмитрий]

DevMan,
1. Ну выкладка на прод она по-моему в разработку входит.
2. Даже прямыми руками поддерживать на деве нужные версии техстэка в зоопарке микросервисов занятие утомительное.

[Sanes]

Дмитрий, и что там может так сильно отличаться в этом стеке? (LAMP/LEMP)

[Дмитрий]

Sanes, ну как бы более менее большие системы, особенно микросервисные выходят, за рамки язык, вебсервер, RDBMS.

[Sanes]

Дмитрий, автор сайтики на Laravel собирает. Кто работает с огромными распределенными системами, такие вопросы здесь не задаёт.

[Дмитрий]

Sanes, вопрос накладных расходов всплывает часто.

[Sanes]

Дмитрий, поэтому и не надо Docker везде пихать. Особенно в этом стеке. Каждый хост можно настроить, как душе угодно. Я для себя написал Ansible сценарии, и web-приложение, чтобы быстро настроить.
С панелями управления сейчас как-то тяжко. То цены взвинтят, то в политику ударятся.

[Дмитрий]

Sanes, я нигде не говорил что докер надо пихать везде. При этом docker это уже стандарт разработки.

[Sanes]

Дмитрий, это стандарт программистов, которые не умеют настраивать окружение.

[Дмитрий]

Sanes, вы сказали глупость.

[Антон В.]

похоже начинается HolyWar

Answer 2

[mayton2019]

При разработке docker не ставились задачи - догнать bare-metal. Главная задача - виртуализация и оркестрация.
Если у вас нет таких задач то возможно и docker вам просто не нужен. Ставьте софт на железо и
не будет таких вопросов.

Comments

[Антон В.]

Спасибо за ответ. Да я понимаю, что накладные расходы будут обязательны. Было бы хорошо, примерно понимать о каких цифрах идет речь при работе веб портала.

Докер сильно привлекает скоростью развертывания на новом месте. Настройки сервисов и их зависимые части в одном месте а не разбросаны по операционной системе, легко контролировать.

На локалке в докере обыграны только основные контейнеры и все довольны. А вот за продакшн страшновато.

Я сейчас столкнулся с тем что после переезда, нужно заново настроить на новой машине ВСЕ. начиная от прав и пользователей и ssh nginx php myslq node npm supervisior turn/stun postfix cron backup, ну прям ужас вызывает... понятно что все по отдельности это легко и понятно... и истории команд все есть... но сделать это снова......... годы уже не те :)

[mayton2019]

Антон В., ваша конфигурация не сильно уникальная. Поищите образы в hub.docker.com максимально похожие. Унаследуйтесь от них. Возможно там дописывать надо будет минимум.

Кстати все кто пользовали docker-compose - постепенно переходят на kubernetes.

[Антон В.]

mayton2019, прийму к сведенью, спасибо

[Антон В.]

mayton2019, возможно вы и правы, и мне на самом деле не нужен докер для текущей стадии проекта.
Последовательность мыслей была такова.
1. При разработке на локалках, докер - это спасение для быстрого развертывания рабочего приложения. Очень удобно и быстро, при этом вопросы производительности и подводных камней абсолютно не интересны.
2. Возникает ситуация, когда нужно переехать на другой сервер или взять приложение за основу другого проекта, возникает мысль, а как сделать так что бы заново на продакшине не настраивать весь стек.
3. Условие: продакш, должен работать как можно быстрее и надежно. :D

показалось, что может быть докером, это можно было решать задачу с развертыванием на продакшине.
А может быть для этой задачи лучше подойдет Ansible или что еще?

Что посоветуете?

[Roman K]

docker

Главная задача - виртуализация

уволить

Answer 3

[ky0]

Везде, кроме высоконагруженных баз данных (ну и вообще хайлоада) падением производительности в докере почти всегда можно пренебречь.

Comments

[Антон В.]

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

В связи с этим хочется понять, в описанном стеке на одном хосте, какова будет разница в скорости под нагрузкой.

Мне не хватает глубокого понимания взаимодействия конейнеров в докере, что бы самому это прикинуть.

Поэтому хотелось бы узнать у профи, приблизительно, какой процент берет на себе докер при взаимодействии контейнеров. если сравнивать с сервисами на чистым железом.

С одной стороны есть ощущение, что это должен быть мизер на уровне 2-5%
а другой стороны есть опасение что это разница будет 15-20%

так вот если бы это было 2-5% то конечно выбора за докером.
но если цифры 10-20% то субъективно это дорого, и есть смысл по играться с железом, дописать скрипт развертывания на чистом железе.

[Roman K]

Антон В.,

так вот если бы это было 2-5% то конечно выбора за докером.
но если цифры 10-20% то субъективно это дорого, и есть смысл по играться с железом, дописать скрипт развертывания на чистом железе.

Ты ещё так молод:)

Даже 20% оверхэд стоит того в 99% случаев, если мы не говорим про разработку на го с кросс-компиляцией и одним бинарником на выходе. Но 20% оверхэда нет, а конкретную цифру никто сказать не сможет, потому что оверхэд — он разный. Если у тебя большую часть времени ответа занимают CPU операции — оверхэд будет в районе нуля. Если твоё приложение — это эхо-сервер, то оверхэд может быть и 50%.

Answer 4

[Roman K]

Если осознать, что докер — это НЕ ВИРТУАЛИЗАЦИЯ, как многие умники тут пишут, то всё звучит не так страшно. Докер контейнер исполняется на той же хостовой машине, задача докера — изоляция фс и сетевого стека. Производительность контейнеров nearly identical to native (это ровно то, чем поделился Дмитрий) за исключением сетевого стека, если не выбираешь полностью хостовый network.

Однако, если твоё приложение на одной тачке не пытается обслужить десятки или сотни тысяч запросов в секунду, то абсолютно без разницы, в докере оно или нет.

Comments

[mayton2019]

Пошла борьба определений?

Containerization is operating system-level virtualization or application-level virtualization

https://en.wikipedia.org/wiki/Containerization_(co...

[Roman K]

mayton2019, никакой борьбы нет. Сказав "виртуализация" в айтишной среде, вы можете быть уверены, что 99.9% респондентов услышат что-то около "openvz", "kvm", "xen" и т.п. И именно вы сейчас распространяете в этой же среде смуту, а потом ко мне (и далеко не только ко мне) приходят программисты на собеседования и говорят "нууу ээммм нууу докер там в виртуалках запускает приложения".

Да, это виртуализация в самом широком понимании этого термина, но не в том понимании, которое укрепилось за этим словом де-факто. Когда вы слышите слово "свастика", вам в первую очередь в голову не приходит "пожелание удачи", а кое-что другое, не так ли?

[mayton2019]

Roman Kitaev, да но вы полностью отвергаете онтологию этих терминов. Разве это научно?

Answer 5

[Sanes]

Nginx
PHP-FPM
Mysql
Laravel-echo-server (node) - websocket
Redis

Не нужен здесь Docker.

Comments

[Антон В.]

спасибо за ответ. а если добавить к списку node npm supervisior turn/stun postfix cron backup ?

[Sanes]

Антон В., добавьте. В чем проблема?

[Антон В.]

Думаю что проблема возникает когда нужно переехать, или использовать проект что бы на его основе новый делать. Лучше такое решать Ansible сценарием?

[Sanes]

Антон В., я делаю с помощью Ansible. Примерно так. Сразу нормально настраивается окружение.
Представьте, что вам потребуется настроить окружение на VDS. Он и так уже просел в производительности, а вы его сверху докером добили.

[Антон В.]

Sanes, ооо, а это на самом деле очень ценная мысль! Сегодня всю ночь читал про Pros.Cons докера для лива. И правда ведь вируталка потребляет ощутимое количество ресурсов, если на него еще докер посадить... то как то не вкусно получается

[Антон В.]

Sanes, благодарю за плейбук