Тестирование производительности 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, оставляя ресурсы для выполнения конкурирующих задач, развернутых на этом же физическом сервере.