Мы тут запускаем последнее в России коммерческое облако, и один из побочных эффектов этого процесса — настраиваем тесты всех конкурентов, чтобы понимать объективную картину. Прошлый тест был про переподписку ядер процессора, и он вызывал нехилое такое пригорание пятой точки у суперпереподписанного Таймвеба (хотя по цене за производительность они оказались вполне в порядке).

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

Облака в тесте:

1. Selectel.
2. Cloud.ru.
3. Timeweb.
4. VK.
5. Yandex.
6. Rostelecom.
7. H3LLO.CLOUD.

Коротко о результатах

Radar chart по трём показателям: производительность, стоимость к производительности и задержка инвертированная. Больше площадь — лучше

• Timeweb показал одну из самых низких производительностей, но при этом снова хорошую цену за единицу вычислений.
• VK Cloud и Яндекс оказались аутсайдерами: и производительность не впечатляет, и стоит дорого. У Яндекса есть ограничитель на максимальную производительность.
• Потом вы просили добавить нас в тесты, чтобы потом можно было предъявить, если что, и мы добавили. Нам надо было установить цену для своих тарифов, мы взяли её как медианное значение между Cloud.ru и Selectel.

Нельзя просто взять и протестировать

Мы не ожидали, что это обернётся почти масштабным научным исследованием, а не простым «запустил и померил». Делов-то было на 20 минут, как казалось вначале. Ну, поставим бенчмарк, запустим скрипт, получим циферки, забабахаем красивые графики. А в итоге погружаешься в какую-то научную диссертацию, где каждое число может быть оспорено, а каждое методологическое решение требует обоснования.

Потому что вы нас немного заклевали за подход «херак-херак и в продакшен» на первом тесте. Хотя он вполне решал свою задачу — оценить производительность связки vCPU-RAM на машинах с одинаковыми характеристиками у разных провайдеров. Или, проще говоря, выяснить, кто же больше охренел )

В общем, методология. Сразу решили не изобретать велосипед и взяли встроенный в PostgreSQL тест pgbench. Он создаёт три таблицы разного размера, которые отличаются друг от друга в 10 и в 100 000 раз по числу записей. Выбрали фактор масштабирования 200, и это дало нам таблицы размером 200, 2000 и 20 миллиона записей. Достаточно, по нашему мнению, чтобы проверить, как облака справляются с нагрузкой.

Главная проблема методологии: если вы запускаете тесты с локального компьютера, то результаты будут зависеть от вашего интернет-соединения. Человек в другом городе с другим провайдером получит совершенно иные цифры. Все тесты запускались с виртуальных машин, которые находились в той же подсети и зоне доступности, что и тестируемые базы данных. Так мы исключили влияние внешних сетей.

• База данных Postgres 16.
• 4vCPU + 16 Гб RAM + 40 Гб SSD (где был выбор между дефолтным флейвором БД и настраиваемым сайзингом, мы выбирали дефолтный флейвор).
• Где был выбор между Ice Lake vs Cascade Lake мы выбирали Ice Lake.
• Без пулинга, репликации и бекапов.
• Без тонкой настройки дополнительных параметров конфигурации Postgres.
• Для бенчмаркинга выбрали стандартный pgbench, который входит в состав Postgres.
• Для минимизации времени отклика pgbench запускался из виртуальных машин находящихся в той же приватной подсети, что и Managed Postgres, без SSL.
• Проводили 4 итерации: 1 разогревочная + 3 фактических.
• Бенчмаркинг проводился в рабочее время.

4 стандартизированных нагрузки pgbench:

• default, «Стандартная нагрузка TPC-B»
• simple_update, скрипт обновляет баланс в таблице `pgbench_accounts`
• select_only, скрипт выполняет выборку данных из таблиц `pgbench_accounts`, `pgbench_branches` и `pgbench_tellers`
• complex_write, скрипт обновляет балансы в таблицах `pgbench_accounts`, `pgbench_tellers` и `pgbench_branches`, моделируя сложную транзакцию

Отказались от использования 2 нагрузок, поскольку по результатам предварительных тестов бенчмаркинга они не добавляли информативности к результатам от уже существующих стандартных тестов, а только удлиняли бенчмаркинг:

• join_heavy: скрипт выполняет соединение таблицы `pgbench_accounts` самой с собой несколько раз, что позволяет оценить производительность при выполнении joins
• insert_with_indexes: скрипт вставляет новую запись в таблицу `pgbench_history` и обновляет баланс в таблице `pgbench_accounts`, что позволяет оценить производительность при выполнении операций вставки и обновления с использованием индексов

Измеряли 2 метрики:

• Количество транзакций в секунду (TPS): Сколько операций база данных может выполнить за одну секунду.
• Время отклика запросов: Сколько времени требуется базе данных для выполнения запроса.

Коэффициент стоимости считался в руб/час/TPS.

Параметры бенчмаркинга:

• scale factor = 200 (это значит что в базе будут 3 таблицы, по 20 млн записей, 2 тыс. записей и 200 записей соответственно).
• Одновременные клиенты базы данных client_counts = [16, 32, 64].
• Рабочие потоки thread_counts = [32, 64, 128].
• run_time одной итерации = 30 секунд.

Всего для каждого провайдера было проведено 108 тестов: 3 различных client_counts * 3 различных thread_counts * 4 типа нагрузки * 3 итерации.

Где только можно, отключали репликацию и пулинг подключений. С пулингом интересный момент: он реально помогает базе данных не захлебнуться при нагрузке, но мы его специально отключали, чтобы увидеть «чистую» производительность самой СУБД без костылей.

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

Некоторые приключения

Сберклауд и Яндекс просто не дают подключиться к базе извне их экосистемы. То есть, если у вас приложение не в их облаке, вы к своей базе данных подключиться не сможете. Занавес.

Обе этих компании демонстрировали потрясающий user experience — он был совершенно не приспособлен для обычного человека, который достаточно издалека знает, что такое сеть. По-хорошему нужно в этих сценариях с этими провайдерами приглашать нормального сетевика, который вам всё настроит. Если вы не профессиональный сетевой инженер, настроить подключение — это квест уровня «найди все тайные комнаты в Хогвартсе». Причём на старых аккаунтах всё работает совсем не так, как на новых.

На новых всё запускалось предельно плохо, непонятно, с какими-то невнятными ошибками уровня «обратитесь в поддержку, мы не можем что-то создать». Решение такое: старые аккаунты мы не удалили, но убрали из них старые организации и перевоссоздали новые организации в рамках старого аккаунта. И там всё было совершенно иначе. Вообще другой UX.

Таймвеб нас забанил тогда, когда мы начинали тестировать с локальной машины. Несколько раз мы запускали и перезапускали скрипт. Надо сказать, что мы его запускали синхронно с другими провайдерами. И в определённый момент мы увидели странное поведение от Таймвеба. Сначала посыпались ошибки, а потом скрипт сам перестал работать, потом перестал работать сайт Таймвеба с нашего публичного IP )

Мы не делали ничего необычного — просто запускали стандартный pgbench, который создаёт нагрузку не больше, чем обычное приложение. Примерно так интернет-магазин обращается к своей базе данных. На следующий день Timeweb нас разблокировал, и мы попытались запустить тесты уже с виртуальной машины внутри их сети. И тут произошло что-то странное: они сделали что-то со своим кластером managed db, что он вдруг резко стал показывать производительность гораздо выше, чем всё, что у нас было в тестировании — даже выше, чем наш собственный локально размещённый сервер GEN11 на Xeon 6430.

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

Ростелеком — наш гомерический смех продолжается! Их мы вообще исключили из теста. Потому что снова бюрократия. Прошлый эпизод диких приключений вот. Так вот, теперь мы не смогли запустить облако. Потому что база данных до сих пор на согласовании у их менеджера.

Казалось бы, 21-й век. Но нет, Ростелеком продолжает жить в эпохе «ждите звонка менеджера». Я готов предположить, что они так сделали для того, чтобы избежать потока людей с непонятной репутацией.

Результаты

Зависимость скорости транзакции к задержке

Количество транзакций в зависимости от соединений

Количество транзакций в секунду по типам нагрузки

Кривая распределения по совокупности тестов всех вместе. Чем выше верхняя группа точек, тем лучше и больше вероятность получить более высокую скорость транзакции

Отношение стоимости к производительности

Распределение количества транзакций в секунду

Среднее количество транзакций по провайдерам

Средние задержки по провайдерам

По результатам тестов явно выделились два лидера: Клаудру и Селектел с практически идентичными показателями. Разница между ними была в пределах статистической погрешности.

ВК Cloud оказался примерно на 30–40% ниже лидеров. Это, кстати, полностью коррелирует с нашими предыдущими тестами виртуальных машин на Geekbench — похоже, у ВК просто железо послабее.

С Яндексом получилась совершенно абсурдная ситуация. Как только мы пытались подключить 64 клиента — тесты валились с ошибками. Мы просто не могли провести полноценное тестирование, отрезав весь верхний диапазон производительности. Как это интерпретировать? Да никак. Как будто вы пришли тестировать машину на автодроме, а вам говорят: «Извините, больше 60 км/ч ехать нельзя, у нас такие правила».

У большинства хостингов кривая выходит на плато или даже падает при увеличении числа соединений. А у нас для сравнения — практически линейный рост — то есть чем больше клиентов подключается к базе, тем выше общая производительность. Мы не ожидали такого эффекта. Железо действительно решает!

В результате по цене — Timeweb, несмотря на низкую абсолютную производительность, выглядит довольно неплохо. Они компенсируют технические ограничения привлекательной ценой. Как я уже говорил, VK Cloud и Яндекс — производительность не впечатляет, стоит дорого.

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

Дисклеймер

Важный момент: все тесты мы проводили только в рабочие дни и только в дневное время.

Никаких ночных или выходных измерений.

Ограниченное количество конфигураций тестов: 3 варианта thread counts и 3 варианта client counts, только 1 вариант scale factor. Фиксированная конфигурация — тестировалась только одна конфигурация CPU/RAM/SSD (4vCPU + 16 Гб RAM + 40 Гб SSD).

Есть влияние факторов, не зависящих от работы сервиса Managed Postgres, таких как сетевая задержка, переподписка, колебания нагрузки в рабочее время у разных провайдеров. Мы минимизировали сетевые задержки за счёт проведения теста на виртуальных машинах в той же зоне доступности и подсети, что и тестируемый сервис Managed Postgres. Тесты выполнялись параллельно, где это было возможно, чтобы минимизировать влияние времени суток на нагрузку на инфраструктуру облачного провайдера; там, где было невозможно обеспечить параллельность, мы выполняли тест в другие дни в примерно одинаковое время суток.

Длительность исследования (несколько дней) и продолжительность итерации (30 секунд) могут быть недостаточны для выявления снижения производительности в долгосрочной перспективе. Мы включили 3 итерации для статистической значимости плюс 1 предварительная прогревочная итерация.

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

Итого: тест — не измерительный инструмент, а ориентир! Результаты стоит рассматривать как примерный подход. Если вы выбираете хостинг для своего проекта, лучше провести собственное тестирование с учётом специфики вашей нагрузки.

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

P.S. Про запуск и когда нас можно будет потрогать руками. Вот тут принимаем в бета-тестеры и даём бесплатный доступ. Сам запуск на прод примерно через месяц, будут большие бесплатные ресурсы для демо.