Тестирование производительности Drupal: MySQL vs PostgreSQL часть 2

В первой части я провел синтетический тест скорости инициализации Drupal и вывода "Hello world" для MariaDB и PostgreSQL. Тест синтетический, т.к. в реальной жизни Drupal выводит ноду и для ее вывода и шаблонизации требуются и процессорное время и запросы в БД (которая у нас и есть узкое место по результатам предыдущих тестов). Тогда победителем оказалась MariaDB. Но хочется протестировать что-то более близкое к реальным задачам на той же аппаратной конфигурации.

Методика тестирования

С помощью Devel генерируется 1 млн нод с числом комментариев от 0 до 6 к каждой ноде. Дополнительные поля к нодам не добавляются, но добавляется синоним. Кеш Drupal в Redis. Включено небольшое число стандартных модулей и модуль тестирования нагрузки. Для имитации нагрузки авторизованного пользователя встроенное кеширование Drupal не используется. Кеширование на балансировщике не используется.

Тестовый модуль случайным образом выбирает любую ноду из миллиона, рендерит и выводит пользователю.

 
function random_test_perf() {
  $nid = rand(1,1000000);
  $node = node_load($nid);
  if ($node->nid) {
    $view = node_view($node);
    $render = drupal_render($view);
    return $render;
  }
  return "can not load node\n";
}

При этом по данным модуля Devel делается 20 запросов в БД.
Запросы в БД Drupal для вывода одной ноды
По сравнению с предыдущим тестом увеличилось в два раза число запросов в БД. Скорее всего это будет означать, что время генерации страниц увеличится в два раза в большинстве случаев, а разница между 2 и 5 нодами серверов приложений станет еще менее заметна.

Ниже представлен скриншот загрузки процессоров серверов пяти серверов приложений (14 ядер) и справа загрузка сервера БД под MariaDB (24 ядра) при 400 конкурентных запросов.

Загрузка процессоров при 400 конкурентных запросов к случайной ноде Drupal7 и загрузка сервера БД MariaDB.

MariaDB/MySQL

Во время проведение теста число запросов в секунду уменьшилось с 24 000 (в предыдущей серии тестов), до 8 тыс. Что существенно сказалось на итоговую производительность. Не смотря на миллион нод, попадание в кеш БД 100%.

До 250 конкурентных подключений добавление нод не дает вклада в производительность, что означает, что сервера приложений недогружены и время генерации страницы зависит исключительно от скорости работы с БД. С 250 конкуретных подключений и до 500 меняется закон и добавление нод позволяет сохранить время генерации страницы почти на одном уровне. Это означает, что запас производительности базы данных еще есть, а у серверов приложений уже нет. Затем начинается плавный рост времени генерации с повышением нагрузки.
Разница между 2,3,4 нодами незначительна, на уровне погрешности измерений.
Таким образом, мы опять уперлись в БД. Т.к. на практике время генерации страницы больше 1 с. является малоприемлемым, смысла покупать несколько серверов приложений нет, т.к. производительность не увеличится.
Или есть?
Я провел еще один тест с помощью JMeter цель которого: измерить среднеквадратичное отклонение для 1 и 5 нод т.к. есть основания подозревать, что при одной ноде и сильной нагрузке на сервер разброс от среднего значения на больших нагрузках может оказаться очень большим.
Собственно, что и подтвердилось даже при малом числе клиентов. Т.е. отклонения от измеренного среднего при использовании 1 ноды будут примерно в 1.5 раза больше чем при 5 нодах.

PostgreSQL

По сравнению с предыдущим тестом, пиковая производительность не изменилась и осталась на уровне 15 тыс.транзакций в секунду. Попадание в кеш 100%. Выход на пиковую производительность с полной утилизацией всех процессоров происходит уже при уровне конкурентности в 100 запросов/c.

Закон во всех случаях линейный.  Производительность 3,4,5 нод находится на одном уровне, поэтому не имеет смысла покупать более трех серверов приложений. Добавление второй и третьей нод приложений дает вклад в производительность и этот вклад может быть заметен. Так, при 450 конкурентных запросов, время генерации страницы для трех нод в два раза меньше одной ноды.
Одна нода с хорошим временем генерации страницы (меньше 250 мс.) может справиться со 150 конкурентными подключениями.

PostgreSQL vs. MariaDB/MySQL

В прошлый раз при тестировании производительности роутера Drupal победила MariaDB. С изменением теста (добавлением полезной нагрузки в виде вывода ноды), победитель изменился. С уверенным отрывом лидирует PostgreSQL. На графике представлено сравнение производительности MariaDB и PostgreSQL для 1 и 5 нод.
Если считать, что время генерации страницы не должно превышать 1 секунды, то 1 нода сервера приложений и PostgreSQL работают быстрее 5 нод серверов приложений с MariaDB вплоть до 450 конкурентных запросов.

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

Тест электронной библиотеки MariaDB vs. PostgreSQL

На самом деле тестирование с самого начала задумывалось для моего проекта электронной библиотеки ELiS: http://demo.elibsystem.ru. Особенность библиотеки - большой объем данных о книге, извлекаемые при показе книги (вынутый текст с каждой страницы, постраничные права доступа и т.п., которые хранятся в БД и кешируются в Redis). На этом же оборудовании из отдельной БД, Redis и 5 нод серверов приложений проведен тест библиотеки: выбиралась, загружалась и рендерилась случайная книга. Такая нагрузка существенно тяжелее отображения случайной ноды как по числу запросов, так и по объему кешированных данных и затратам процессора на рендеринг страницы.
Тестирование проводилось JMeter и показало, что небольшое преимущество имеет PostgreSQL, при этом от числа нод медиана не зависит вообще. Такой результат я связываю с тем, что большую часть времени большой объем данных передается по сети и обе БД полностью нагрузить не удается. Типовая производительность MariaDB - 4 тыс. запросов/c, PostgreSQL - 8 тыс. транзакций/c с пиком до 12.5 тыс.

Однако, т.к. данных намного больше чем просто с загрузкой одной ноды, вычислительная нагрузка по обработке и рендерингу оказывается больше предыдущего теста и это приводит к сильной зависимости среднеквадратичного отклонения от числа нод. Измерения приводятся опять только для MariaDB, однако, для PostgreSQL результаты аналогичны.
Отсюда видно, что уже при 50 конкурентных запросов, среднеквадратичное отклонение близко к медиане времени ответа, что означает большой разброс времени отклика. Пять же нод показывают маленькое среднеквадратичное отклонение, что означает высокую стабильность результатов. Отсюда вывод: из того что среднее время отзыва не зависит от числа нод серверов приложений еще не следует, что надо покупать минимально-возможное число серверов. Если сервера приложений сильно перегрузить, это может привести к большой вариативности во времени ответа, хотя среднее время может быть и будет допустимым.
В этом конкретном случае видно, что желательно не превышать 50 одновременных клиентов. При 100 одновременных клиентов одного сервера приложений недостаточно. В качестве БД лучше PostgreSQL.

Выводы

Какая база будет работать быстрее существенно зависит от ваших данных. В некоторых случаях быстрее будет MySQL/MariaDB, в других PostgreSQL, в третьих разница будет минимальна, в четвертых вы упретесь в сеть и разницы не увидите. Увы, но на ваших данных и железе вам надо провести тест самостоятельно...

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

Для вывода простой одиночной ноды Drupal авторизованному пользователю без большого числа включенных модулей в условиях выделенного сервера базы данных с большим объемом ОЗУ (высокий процент попадания в кеш) и выделенного сервера приложений, уверенную победу одерживает PostgreSQL.
Рекомендация к покупке при этом следующая: если уровень конкурентных запросов у вас меньше 100, можно обойтись одним сервером приложений. Если больше, то покупка трех серверов приложений позволит увеличить число конкурентных подключений в два раза в рамках того-же времени генерации страницы и уменьшит разброс времени генерации от среднего. Покупка более трех серверов приложений производительность не увеличит.

Однако, эта рекомендация не подходит для VPS/Shared hosting т.к. утилизация всех 24 ядер CPU на 100% PostgreSQL происходит уже при 100 конкурентных подключений, в то время как MariaDB хоть и медленнее, более экономно использует CPU, оставляя ресурсы для выполнения конкурирующих задач, развернутых на этом же физическом сервере.

Популярные сообщения из этого блога

Как оживить корпоративный сайт?

Мастерим компьютер для прямых интернет трансляций и записи с видеокамеры или системы ВКС