Статьи

LinkBenchX: эталонный тест, основанный на частоте запросов на прибытие

Февраль 19, 2018

[Эта статья написана Вадимом Ткаченко]

В Sysbench была реализована идея эталонного теста, основанного на коэффициенте «запросов на поступление», о котором я писал в посте, озаглавленном « Внедрение нового типа эталонных тестов » еще в 2012 году. Однако Sysbench обеспечивает только простую рабочую нагрузку, поэтому, чтобы иметь возможность сравнивать InnoDB с TokuDB, а затем MongoDB с Percona TokuMX , я хотел использовать более сложные сценарии. (И TokuDB, и TokuMX являются частью линейки продуктов Percona, в случае, если вы пропустили  Tokutek, который теперь входит в семейство Percona .)

Благодаря Facebook — они предоставляют  LinkBench , эталон, имитирующий нагрузку на базу данных социальных графов. Я сделал изменения в LinkBench, которые доступны здесь: https://github.com/vadimtk/linkbenchX . Резюме изменений

  • Вместо генерации событий в цикле мы генерируем события с помощью  requestrate и отправляем событие для выполнения одному из доступных потоков реквестера.
  • В начале мы устанавливаем N ( requesters) подключений к базе данных, которые по умолчанию простаивают и просто ждут, пока не выполнится входящее событие.
  • Основным выходом эталонного теста является время отклика 99% для операций ADD_LINK (запрос INSERT + UPDATE) и GET_LINKS_LIST (запрос диапазона SELECT).
  • Связанный вывод — это параллелизм, то есть количество потоков реквестеров, активных в течение периода времени.
  • Возможность часто публиковать статистику (с интервалом 5-10 секунд); таким образом, мы можем видеть тенденцию и стабильность результата.

Также я предоставляю Java-пакет, готовый к выполнению, поэтому вам не нужно компилировать его из исходного кода. Он доступен на странице релиза по адресу  https://github.com/vadimtk/linkbenchX/releases.

Таким образом, основной целью теста является время отклика и его стабильность во времени.

Для примера, давайте посмотрим, как TokuDB работает при разных частотах запросов (это был быстрый тест, чтобы продемонстрировать возможности тестирования, а не предоставить цифры для TokuDB).

Первый график — это время отклика 99% (в миллисекундах), измеряемое каждые 10 секунд для скорости поступления 5000, 10000 и 15000 операций в секунду:

resp1

или, чтобы сгладить пики, тот же график, но со шкалой Log 10 для оси Y:
соответственно, журнал

Таким образом, есть два наблюдения: время отклика увеличивается с увеличением скорости поступления (как это и должно быть), и есть периодические всплески времени отклика.

И теперь мы можем построить график параллелизма (сколько потоков заняты работой над запросами)…
конц

… С объяснимым наблюдением, что требуется больше потоков для обработки большего числа поступлений, а также во время пиковых нагрузок все доступные 200 потоков (это настраивается) становятся занятыми.

Я хочу принять LinkBenchX для запуска идентичной рабочей нагрузки с MongoDB.
Текущая схема проста

CREATE TABLE `linktable` (
  `id1` bigint(20) unsigned NOT NULL DEFAULT '0',
  `id2` bigint(20) unsigned NOT NULL DEFAULT '0',
  `link_type` bigint(20) unsigned NOT NULL DEFAULT '0',
  `visibility` tinyint(3) NOT NULL DEFAULT '0',
  `data` varchar(255) NOT NULL DEFAULT '',
  `time` bigint(20) unsigned NOT NULL DEFAULT '0',
  `version` int(11) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (link_type, `id1`,`id2`),
  KEY `id1_type` (`id1`,`link_type`,`visibility`,`time`,`id2`,`version`,`data`)
) ENGINE=TokuDB DEFAULT CHARSET=latin1;
CREATE TABLE `counttable` (
  `id` bigint(20) unsigned NOT NULL DEFAULT '0',
  `link_type` bigint(20) unsigned NOT NULL DEFAULT '0',
  `count` int(10) unsigned NOT NULL DEFAULT '0',
  `time` bigint(20) unsigned NOT NULL DEFAULT '0',
  `version` bigint(20) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`,`link_type`)
) ENGINE=TokuDB DEFAULT CHARSET=latin1;
CREATE TABLE `nodetable` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `type` int(10) unsigned NOT NULL,
  `version` bigint(20) unsigned NOT NULL,
  `time` int(10) unsigned NOT NULL,
  `data` mediumtext NOT NULL,
  PRIMARY KEY(`id`)
) ENGINE=TokuDB DEFAULT CHARSET=latin1;

Я открыт для предложений относительно правильного оформления документов для MongoDB — пожалуйста, оставьте свои рекомендации в комментариях.

33
Share: