Пост рассказывает о моем неудачном тесте производительности, а также показывает пару неправильных цифр производительности 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.micro			i3.large
	GP2	IO1
		3000 PIOPS	6000 PIOPS
Цена сервера	$10	$10	$10	$130
Цена диска	$1	$9**	$18**	$1
Цена PIOPS	-	$195	$390	-
Цена, итого	$11	$214	$418	$131
CPU	10-100%	10-100%	10-100%	200%
ОЗУ	1GB	1GB	1GB	16GB
IOPS	100, до 300,000 в burst	3,000	6,000	100,000
Запись, постоянная нагрузка	700 (disk throttled) 1,700 (CPU throttled)	1,300	2,300	27,000***
Запись, burst	2,700	10,000	>10,000
Чтение из 100k набора, stable load	<4,000	11,000*	21,000*
Чтение из 100k набора, burst	35,000
Чтение из 1m набора, stable load	<4,000	3,000	5,000	43,000*,***
Чтение из 1m набора, burst	6,000

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

i3.large

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

Характеристика	Размер БД, ключей
	100k	1m	10m	30m
Скорость чтения	41,407	42,977	43,220	17,286*
Задержка чтения, до 1ms	60.14%	62.34%	60.27%	2.88%
Задержка чтения, до 5ms	99.97%	100.00%**	99.99%	99.16%
Максимальная задержка чтения	6ms**	3ms**	13ms**	14ms**
Скорость записи	34,831	26,911	15,967*	10,353*
Задержка записи, до 1ms	11.96%	8.66%	5.22%	2.88%
Задержка записи, до 5ms	99.53%	97.50%	96.15%	82.65%
Задержка записи, до 50ms	100%	99.99%	99.74%	99.68%
Задержка записи, до 100ms	100%**	99.99%	99.84%	99.75%
Задержка записи, до 300ms	100%**	99.99%	99.94%	99.87%
Задержка записи, до 500ms	100%**	100%	99.96%	99.91%
Максимальная задержка записи	17ms**	604ms	3104ms	5059ms

* читай «не менее чем», узкое место в этих тестах — скорость передачи с сервера где был запущен 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 за месяц)

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