Pull to refresh

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

Reading time 3 min
Views 2.3K
Пост рассказывает о моем неудачном тесте производительности, а также показывает пару неправильных цифр производительности 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 за месяц)

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

Articles