Комментарии 31
производительность
Самый главный вопрос - как рассчитывается производительность ? Что понимается под производительностью СУБД ?
таблицы размером 200, 2000 и 20 миллиона записей. Достаточно, по нашему мнению, чтобы проверить, как облака справляются с нагрузкой.
Почему вы так уверены ?
Измеряли 2 метрики:
Количество транзакций в секунду (TPS): Сколько операций база данных может выполнить за одну секунду.
Время отклика запросов: Сколько времени требуется базе данных для выполнения запроса.
Результат считали как среднее арифметическое ? Время отклика запроса - как рассчитывали?
Среднее количество транзакций по провайдерам
Среднее арифметическое ?
Длительность исследования (несколько дней) и продолжительность итерации (30 секунд)
Сколько всего получилось итераций ?
Надо бы 99 перцентиль
Почти на все ваши вопросы ответ есть в тексте статьи. Итераций — 108. Среднее — это среднее арифметическое, но на графиках можно и разброс увидеть. Время отклика считает сам pgbench.
Почему мы уверены, что таких таблиц хватит для теста? База с выбранным нами сайзингом занимала порядка 2ГБ. Мы специально выбрали такой размер, чтобы он не был ограничением.
Что понимать под производительностью — очевидно, основной продукт СУБД — количество выполненных транзакций за период времени (секунда). Это, по сути, сколько запросов сможет переваривать приложение.
Latancy — второй фактор, играющий значение для веб-приложений, сайтов и различных бэкендов. Это задержка, которая добавляется ко времени ответа приложения клиенту.
Конечно, можно представить и другие сценарии использования СУБД (например, аналитика). Тут — тяжелые джоины и сложные операции, а также скорость записи (если мы собираем данные в ту же базу, где и анализируем).
Но нам для теста вполне достаточно сценария веб-сервера.
Почти на все ваши вопросы ответ есть в тексте статьи.
Ок, вечером прочитаю еще раз повнимательнее.
Среднее — это среднее арифметическое
Со средним арифметическим есть серьезная проблема
https://dzen.ru/a/Z1--cZ4sHEmzLsy5
Я просто на грабли среднего арифметического уже наступал.
Так, что цифрам TPS которые показывает pgbench , я уже давно не доверяю. Потому, что выбросы это норма, особенно, кстати в облачной инфраструктуре.
Что понимать под производительностью — очевидно, основной продукт СУБД — количество выполненных транзакций за период времени (секунда).
А если транзакций нет вообще ? Только select .
Да и транзакция транзакции рознь.
INSERT и UPDATE выполняются в транзакции, но вот влияние на работу СУБД очень сильно отличается .
а также скорость записи
Не только, еще и тяжелые и легкие блокировки.
А есть еще репликация и ожидания IPC.
А если транзакций нет вообще ? Только select .
Да и транзакция транзакции рознь.
INSERT и UPDATE выполняются в транзакции, но вот влияние на работу СУБД очень сильно отличается .
pgbench даже простой селект считает транзакцией (тут под транзакцией имеется в виду любой запрос к БД).
Не только, еще и тяжелые и легкие блокировки.
А есть еще репликация и ожидания IPC.
Поэтому мы и предлагаем каждому тестировать БД под свои нагрузки, а наш тест — это скорее ориентир.
pgbench даже простой селект считает транзакцией
Да, тут согласен. Название не принципиально , назовем sql-statement . Просто , это не является каким то скрытым знанием , характер производительности СУБД при select, insert, update сильно разный.
Поэтому мы и предлагаем каждому тестировать БД под свои нагрузки
Да тема нагрузочного тестирования и особенно анализ результатов давно в работе.
Если любопытно:
https://dzen.ru/a/Z7gmHgBGAHo5m2SS
Выскажу мысль, что тестирование скорости СУБД в облаке занятие неблагодарное . Очень сильноизменяемая инфраструктура в облаке . Сегодня одни результаты завтра другие , потому что виртаулизаторы что там в очередной раз изменили .
Вы большущие молодцы, но запятую все же лучше поставить)
Сберклауд и Яндекс просто не дают подключиться к базе извне их экосистемы.
Не знаю как у сберклауда, а у Яндекса на БД можно повесить публичный IP адрес и спокойно подключаться извне.
Да, сейчас перепроверили, у Яндекса это спрятано очень глубоко (привет дарк-паттернам).
У Яндекса в документации к сервису всё прекрасно расписано в т.ч. с пошаговыми примерами настройки. Более того в консоли во второстепенном меню (меню кластера) внизу есть ссылки на документацию.
Про ограничение на число клиентов кстати в разделе управления пользователями БД для каждого пользователя можно выставить ограничение на число подключений и по умолчанию их как раз 50.
В общем если что-то не понятно у какого-то конкурента достаточно обратиться в их документацию к сервису и вопросов не возникло бы.
Для поиска бутылочного горлышка в дисковой подсистеме (у всех скорее всего какой-то CEPH) просто запускали fio с глубиной 1, блоком 8k и fsync=1
И read/randread/write/randwrite/rw/randrw
Достаточно показательно
Там где oracle с ASM может запускать много потоков и выжимать из диска все, постгре грустит.
То, что работает поверх файловой системы не особо тормозит. А вот 1 поток и fsync причина грусти
С Яндексом получилась совершенно абсурдная ситуация. Как только мы пытались подключить 64 клиента — тесты валились с ошибками
Там ограничение стоит на количество коннектов в настройках юзера, не оно?
Я конечно задам вопрос, считается неприличным в среди нескучных облачных провайдеров - но какой тип диска вы выбрали в VK Cloud? Там, знаете ли, есть несколько типов, и некоторые по лимитам и времени отклика могут отличаться пятикратно. А в яндксе можно запускаться на локальных дисках. Или "я сюда тестировать пришел а не всякими глупостями с выбором типа диска заниматься, давайте мне тестировать"?
Вот такой диск взяли у VK.
А, ну вот и все понятно.
Платформа VKCloud очень жестко тротлит иопсы. А теперь внимание, вопрос - «а сколько у нас клиентов в базе?»
Одновременные клиенты базы данных client_counts = [16, 32, 64].
Рабочие потоки thread_counts = [32, 64, 128]
Выбраный тип (high-iops) обладает достаточно малой латенси - как правило, порядка 250мкс, то есть примерно 4К IOPS в один поток. И как только вы достигаете лимита по операциям в секунду - до конца секунды вас останавливают.
Выходит так, что хотели вы протестировать «скорость PostgreSQL» - а по факту уперлись в лимиты. К тестированию КМК следует подходить несколько тщательней - если бы вы предоставили публике графики того же iostat например (или хотя бы поглядели), то все бы стало понятно сразу «на взлете». Причем, не только читателям, а еще и вам самим.
В общем, все любят котиков (кроме аллергиков - они есть люди подневольные) - но у котиков лапки.
Так ведь тестировалась именно скорость в облаке, в той конфигурации которую это самое облако предоставляет. Что не так-то с методикой и как надо было, по-вашему, делать?
Что не так-то с методикой
Инженерный подход подразумевает, что цель теста не только понять "какие циферки", но и почему такие циферки.
То есть, в данном случае, нужны как минимум метрики CPU, диска и памяти - кроме метрик постгресового бенча. Это позволяет определить "слабое место". Почему это важно? Потому, что причины могут быть разные, и одни причины устранимы а другие нет. Одни причины важны для некоторых кейсов, другие нет.
Ну например... В одном облаке я могу увеличить размер диска до 500GB - и внезапно у меня в два раза вырастет производительность, потому что в два раза упадет средний латенси, который по сути сейчас и является бутылочным горлышком. На тех же процеccорах, на том же объеме памяти, на том же типе диска. И могу увеличить количество процессоров в два раза - и не получить прироста. А в другом наоборот - мне придется накидывать процессоров и памяти.
Вы хотите статью для инженерной аудитории? Дайте читателям инженерные метрики, пусть они обсудят, обменяются опытом и извлекут пользу.
Сберклауд и Яндекс просто не дают подключиться к базе извне их экосистемы. То есть, если у вас приложение не в их облаке, вы к своей базе данных подключиться не сможете. Занавес.
Та ладно? Дальше уже читать интерес пропал, в ТП ходили ? что вам сказали ?
Занимательные результаты.
Коммент немного не по теме, но я тут от скуки залез на Хабр и наткнувшись на вашу статью, череда кликов по ссылкам привела меня к тому, что я прочитал все ваши статьи 😅
В итоге уже знаю, где буду запускать свои проекты и сервак Minecraft для игры с друзьями по выходным)
А если серьёзно, то вы молодцы. Крутой проект и очень интересно следить за закулисьем процесса старта.
Спасибо за статью! А какие конфигурации в селектел вы использовали? Если самые обычные, то они не про скорость, а про доступность. У меня небольшой проект на Cordova с динамической загрузкой товаров, там highfreq неплохо отрабатывает прям.
Кстати, как идея для следующей серии тестов — можно сравнить БД на выделенных серверах, они по скорости покажут более крутые результаты. Хотя тут нужно сравнивать с западными провайдерами, в СНГ пока я слышал про такую услугу только у селектел
>Сберклауд и Яндекс просто не дают подключиться к базе извне их экосистемы. То есть, если у вас приложение не в их облаке, вы к своей базе данных подключиться не сможете. Занавес.
Что за глупость? Спокойно можно подключиться из любой точки мира к кластеру Яндекса. Уже только это может говорить о компетенции таких тестов.
Какие ужасные графики. Зачем от графика к графику цвета менять?
Когда людям нужно работать и чтобы их инфраструктура работала, провайдеры тестируют других провайдеров на производительность, нагружая их ресурсы )))
Почитал. В меру интересно. Не без вопросов к методике и анализу результатов. Но в целом интересно было и для себя открыл возможность такой услуги. "Открыл", т.к не моя тема, но для общего развития и уже есть мысль изучить и поиспользовать в своих целях.
Мы протестировали разные облака в России на скорость PostgreSQL