Comments
C player/Workstation сравнивать не очень полезно. Это не серверная платформа — она не расчитана на запуск и управление множеством машин на одном сервере, у нее основные оптимизации производительности вокруг других вещей (вроде виртуальной графики), из за этих вещей она заведомо покажет плохие результаты для серверных приложений. Никто серьезно не рассматривает этот продукт для серверов.
С ESX история чуть сложнее — как кстати и написано в статье, по EULA VMware результаты бенчмаркинга нельзя публиковать без согласования с VMware. Мы на самом деле меряли их платформу, но результаты были не очень интересные (не было никаких сюрпизов, производительность отличалась от KVM только в деталях), поэтому решили не тратить ресурсы на эти согласования и убрали их упоминания из финального отчета
ну мы же все понимаем, чего стоят графики без оглашения всех настроек libvirt/qemu/kvm? я, например, могу настроить последние так, что openvz окажется в 300 раз быстрее…
У нас не было целей «испортить» конкурентов, мы точно не применяли никаких настроек чтобы сделать их хуже. Вроде бы у инженера который ставил систему есть аккаунт на хабре — я попрошу его зайти и прокомментировать от своего имени
Там другая методология, она дает другие результаты.
В нашей методике на обоих тестовых виртуалках стоят сравнимые ресурсные ограничения (разница только в имплементации на конкретной платформе). до тех пор пока ресурсов хватает — виртуалка показывает в основном их, а не «остаточную производительность» сервера

Спасибо кстати за ссылку, интересно

Боюсь, в своем методе тестирования вы просто поменяли местами переменные.
Грубо говоря, на первом графике видно уравнение: время = запросы * число_виртуалок
А на втором графике что-то типа: score = запросы / время
Переделаем:
время * score = запросы
время = запросы / score
Если приравнять с первым уравнением (не учитывая коэффициенты), получим
запросы / score = запросы * число_виртуалок
1 / score = число_виртуалок или score = 1 / число_виртуалок
Т.е. чем меньше виртуалок, тем больше score, что в общем-то логично :)
Поэтому ваш метод тестирования дает график на третьей картинке, примерно как на первой картинке, только перевернутый по оси X.
Т.е. есть некоторый уровень уровень качества и в каком-то месте он резко падает, даже от малого приращения нагрузки.
Об этом говорит и теория очередей (про которую хорошо рассказано в этой статье).


Как вы уже догадались, наша система виртуализации выиграла по результатам теста (полный отчет можно посмотреть вот по этой ссылке)

По какой ссылке, простите?

Боюсь, в своем методе тестирования вы просто поменяли местами переменные.
Грубо говоря, на первом графике видно уравнение: время = запросы * число_виртуалок


Не совсем так, там другой механизм роста времени (отклика).
До тех пор пока ресурсов хватает, это время отклика в основном определяется суммой latency различных процессов — прохождение запроса по сети, его анализ-обработка, формирование ответа, отсылка ответа и прохождение его по сети.
Анализ, обработка, формирование ответа — эти процессы последовательны по отношению друг к другу, конкретные обработчики как правило однотредовые (таких обработчиков может быть много, но один запрос обрабатывается одним тредом). В результате горизонтальное скалирование ресурсов помогает ему мало — то есть если добавить еще CPU сокетов — время почти не упадет; если увеличить тактовую частоту CPU в два раза — время обработки упадет (почти) в два раза (за вычетом фиксированных latency вроде сетевой).
Поэтому время ответа почти не отличается в ситуациях используется ли 30% или 70% CPU — то есть на начальном этапе нет линейного роста времени ответа с добавлением виртуалок — и на первом графике это видно, скажем при росте от 10 до 80 контейнеров время отклика остается в пределах 0.8 секунды (на KVM за это время растет примерно с тех же 0.8 до 1.1 секунды — опять же, совсем не линейно

Т.е. чем меньше виртуалок, тем больше score, что в общем-то логично :)


Там есть ограничение которое делает график нелинейным — на всех виртуалках стоят ресурсные ограничения сверху. То есть тестируемая виртуалка никогда не покажет производительности сервера целиком. в идеальном мире ее производительность вообще не будет меняться до определенного количества «балластных соседей» (в реальности чуть падает, но нелинейно). И только когда общие ресурсы заканчиваются — на ней это становится заметно.

По поводу зависимости score от количества виртуалок — вот в этой статье есть интересный график
https://virtuozzo.com/performance-expectations-containers/
это vConsolidate (SPECvirt ведет себя аналогично). Его общий score растет (с ростом к-ва VM) пока есть CPU/disk IO ресурсы. Когда они кончаются — score перестает расти и остается относительно линейным. Когда кончается память — score начинает падать из того что система начинает тратить значительно больше ресурсов на resource management (складывание-доставание из swap — типичный пример)

Поэтому ваш метод тестирования дает график на третьей картинке, примерно как на первой картинке, только перевернутый по оси X.

Да, вот это наблюдение очень похоже на правду. Хотя механизмы формирования нагрузок и снятия параметров по сути очень разные — в первом случае мы добавляем соседей и меряем их среднюю производительность; во втором мы плавно увеличиваем «аппетит» соседей, их производительность не меряем но смотрим на производительность одной виртуалки

Но при этом важный для нас параметр — это «эластичность» системы при росте нагрузки. Если нагрузки на всех соседях выросли например на 30% от «рабочей» — насколько упала производительность эталонной системы? это позволяет понять насколько сервера готовы к пиковым или сезонным нагрузкам.
Тут есть параметр который зависит от конкретной системы — то что в статье которую вы привели описано как «борьба с перегрузками». Чем позже наступает момент когда эта борьба становится ресурсоемкой задачей — тем более эластична система по отношению к росту нагрузки
По какой ссылке, простите?

Прошу прощения, ссылку потеряли когда из драфта перетаскивали статью. Поправим. Вот ссылка
полный отчет можно посмотреть вот по этой ссылке

А ссылка то где?
Only those users with full accounts are able to leave comments. Log in, please.