Как неправильно протестировать производительность 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.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 за месяц)

    Спасибо, надеюсь будет полезно кому-нибудь мое даром потраченное время.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 2
    • 0

      Если вам приглянулась LMDB, то советую глянуть libmdbx и libfpta.


      libmdbx — это допеределанный форк LMDB, который продолжает развиваться. В README перечислены примерно все 29 сделанных доработок. О запланированных features можно подсмотреть в конце этих слайдов от доклада c недавнего "Hypeload++2017". Плюс в ближайшее время будет статья на "Хабре".

      • 0
        Спасибо, гляну обязательно

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.