Как неправильно протестировать производительность NoSQL БД в Amazon / Хабрахабр

Пост рассказывает о моем неудачном тесте производительности

А также показывает пару неправильных цифр производительности ARDB c встраиваемой БД LMDB в Amazon EC2 контейнерах

Откуда ноги растут

В проекте ожидается что время от времени нужно будет писать тысячи рядов в БД за минимальное время,

Нагружать основную БД естественно не хочется, после небольшого копания понравилась LMDB

A ARDB — это обертка которая позволяет достучаться до последней как до Redis

К сожалению не смог найти тесты перфоманса данного чуда в Amazon ec2, поэтому решил посмотреть-проверить сам

DISCLAIMER

Пост не о выборе NoSQL БД… Только одна БД тестировалась на разных конфигурациях

Оборудование и установка

Тесты выполнялись в 4 конфигурациях

  • два t2.micro инстанса (в рамках Free Tier) — инстансы слабенькие, когда кредиты есть — дают 100% одного CPU, базовая производительность — 10% CPU
    • GP2 SSD volume — самый медленный SSD, базовая скорость — 100 IOPS,

      (но может время от времени давать до 300,000 IOPS)
    • IO2 SSD volume + 3000 Provisioned IOPS — гарантированные 3000 операций с диском в секунду
    • IO2 SSD volume + 6000 Provisioned IOPS — гарантированные 6000 операций с диском в секунду

  • i3.large БД + m4.xlarge USER — i3.large инстанс имеет выделенный NVMe SSD, который очень быстр

Все компоненты для тестов компилировались из исходников

Типичный сценарий установки

yum install git
yum install gcc
git checkout git://smth
cd smth
make

Ошибки

Основная ошибка — не было планирования… была только идея

Также не учел особенностей Amazon, что большинство сервисов, дают burst при старте активного использования, а потом производительность снижается, это относиться к:

  • Скорости работы диска
  • Скорости сети
  • Скорости процессора, для инстансов с повышаемой производительностью
  • Очень вряд-ли к оперативке, но все может быть

В результате ошибочного выбора инстансов — часто CPU тестируемого сервера не был загружен полностью

В идеале стоило бы имитировать реальный способ использования, но времени как всегда нет…

Без учета всех этих моментов, все цифры, приведенные ниже, только ориентировочные, синтетика господа.

Замеры

Малый набор данных

Набор данных скромный, ждать не хотелось, а получить оценку — да, хотелось

Кол-во ключей: 1,000,000 ключей (читай 650к записей в БД)

Клиентов: 50

Размер записи: 3,000 байт

Тестировалось несколькими последовательными командами

# наполнить БД
./redis-benchmark -n 1000000 -r 1000000 -h ec2-xx-xx-xx-xx.eu-west-2.compute.amazonaws.com -p 16379 -t set -d 3000
# измерить скорость чтения 100k
./redis-benchmark -n 1000000 -r 100000 -h ec2-xx-xx-xx-xx.eu-west-2.compute.amazonaws.com -p 16379 -t get -d 3000
# измерить скорость чтения 1m
./redis-benchmark -n 1000000 -r 1000000 -h ec2-xx-xx-xx-xx.eu-west-2.compute.amazonaws.com -p 16379 -t get -d 3000













Характеристикаt2.microi3.large
GP2IO1
3000 PIOPS6000 PIOPS
Цена сервера$10$10$10$130
Цена диска$1$9**$18**$1
Цена PIOPS$195$390
Цена, итого$11$214$418$131
CPU10-100%10-100%10-100%200%
ОЗУ1GB1GB1GB16GB
IOPS100,

до 300,000 в burst
3,0006,000100,000
Запись, постоянная нагрузка 700 (disk throttled)

1,700 (CPU throttled)
1,3002,30027,000***
Запись, burst2,70010,000>10,000
Чтение из 100k набора, stable load<4,00011,000*21,000*
Чтение из 100k набора, burst35,000


Чтение из 1m набора, stable load<4,0003,0005,00043,000*,***
Чтение из 1m набора, burst6,000


* все данные помещаются в оперативную память
** ограничение Amazon, не более 50 PIOPS на гигабайт
*** читай «не менее чем», узкое место в этих тестах — скорость передачи с сервера где был запущен redis-benchmark

i3.large

Здесь тестирование проводилось на разных размерах БД















ХарактеристикаРазмер БД, ключей
100k1m10m30m
Скорость чтения41,40742,97743,22017,286*
Задержка чтения, до 1ms60.14%62.34%60.27%2.88%
Задержка чтения, до 5ms99.97%100.00%**99.99%99.16%
Максимальная задержка чтения6ms**3ms**13ms**14ms**
Скорость записи34,83126,91115,967*10,353*
Задержка записи, до 1ms11.96%8.66%5.22%2.88%
Задержка записи, до 5ms99.53%97.50%96.15%82.65%
Задержка записи, до 50ms100%99.99%99.74%99.68%
Задержка записи, до 100ms100%**99.99%99.84%99.75%
Задержка записи, до 300ms100%**99.99%99.94%99.87%
Задержка записи, до 500ms100%**100%99.96%99.91%
Максимальная задержка записи17ms**604ms3104ms5059ms

* читай «не менее чем», узкое место в этих тестах — скорость передачи с сервера где был запущен redis-benchmark
** выброшены результаты, для которые задержаны ровно на 200ms по неясной причине, сваливаем вину на Amazon окружение

Выводы

  • Хороший перфоманс для t2.micro инстанса с gp2 диском, за $11 в месяц можно получить БД которая стабильно обрабатывает 1,000 write запросов в секунду, и время от времени дает до 3,000 WPS что достаточно для многих приложений
  • Теоретически производительность ARDB+LMDB на запись когда в БД уже миллион записей можно считать как `diskIOPS / 3`
  • Диски IO1 с Provisioned IOPS не оправдали себя, гораздо дешевле взять оптимизированный инстанс с локальным SSD
  • Для i3.large инстанса — цифры приличные (для $130 за месяц)

Спасибо, надеюсь будет полезно кому-нибудь мое даром потраченное время

Источник