===== (этап 6) Вариант сценария проведения нагрузочного тестирования. =====


> Нагрузочное тестирование предназначено для проверки того, как cистема будет работать под большим количеством пользователей, одновременно, в течение ограниченного периода времени, чтобы смоделировать реальную ситуацию.
> Количество моделируемых пользователей аналогично ожидаемому объему нагрузки пользователей в реальной жизни. 
> Проверяется время отклика Системы, обнаруживаются узкие места и различные ошибки, например такие, как проблемы с кодом и утечки памяти.
> Тестирование позволяет определить какое количество пользователей может обработать Система, прежде чем производительность пострадает.

> TPC-B , TPC-C  (OLTP-систем (онлайн-транзакционная обработка))
>  * эталонный тест, используется для стресс-тестирования пиковой пропускной способности базы данных, имитирует рабочую нагрузку, состоящую из нескольких пользовательских сеансов, подключенных по сети, со значительной активностью дискового ввода-вывода, за исключением любых сетевых и интерактивных операций, чтобы обеспечить наилучшее измерение пропускной способности;

> TPC-H (OLAP-систем (онлайн-аналитическая обработка))
>  * эталонный тест, эмулирующий работу приложений бизнес-аналитики, состоит из набора бизнес-ориентированных специальных запросов и одновременных модификаций данных, анализирует большие объемы данных, выполняют запросы высокой степени сложности.


  * pgbench -- программа для запуска эталонных тестов на PostgreSQL, выполняет последовательность команд SQL, вычисляет среднюю скорость транзакций (транзакций в секунду), использует сценарий, основанный на TPC-B, включающий пять команд SELECT, UPDATE и INSERTна транзакцию, также ПО позволяет протестировать собственный сценарий транзакций;

  * go-tpc -- набор инструментов тестирования рабочих нагрузок на основе тестов TPC для СУБД PostgreSQL, выполняющий тест TPC-H. \\
[[https://github.com/pingcap/go-tpc]]

  * sysbench -- это универсальный инструмент для стресс-тестирования

  * HammerDB -- поддерживающее TPC-C, TPC-H и другие сценарии. для само изучения более профессиональный инструмент \\
[[https://www.hammerdb.com/download.html]]
[[https://www.hammerdb.com/document.html]]

==== Пример использования pgbench. ====

''su - postgres   ## логинимся под УЗ postgres'' \\

''pgbench --help  ## посмотреть доп параметры утилиты'' \\

Создаем пустую БД для тестирования
<code>
psql -c "create database tesdb2;"
</code>
Размер БД может быть изменен согласно запросу Заказчика до необходимого значения, например 1 ТБ. \\
Наполняем данными 1 гб (по требованию заказчика) \\
-i – опция инициализации; запуск команды с этой опцией создаст необходимые таблицы и загрузит тестовыми данными базу данных. \\
-s 68 – параметр scale factor, определяет объём данных. \\
100 000 ? 68 = 6 800 000 строк.
<code>
pgbench -h localhost -d tesdb2 -U postgres -i -s 68
</code>
Проверяем размер создавшейся БД
Можно посмотреть результат в Платформе Tantor.
<code>
psql -c "\l+ tesdb2"
</code>
Выполняем эмуляцию нагрузки
<code>
pgbench -h localhost -p 5432 -c 90 -j 2 -t 100 tesdb2 ## 90 пользователей, 2 потока, 100 транзакций у каждого пользователя
</code>
<code>
pgbench -c 90 -j 25 -P 60 -T 200 tesdb2               ## нагрузить чтение/запись 25 потоков
pgbench -n -c 90 -j 25 -T 200 tesdb2 -b select-only   ## нагрузить только чтение
</code>
-c — количество конкурентных подключений
-P — вывод информации каждые * сек
-T — длительность теста в сек
-j — число потоков
-n — не запускать VACUUM перед тестом.

''TPS'' - могут варьироваться в зависимости от конфигурации системы, но для большинства приложений значение от 100 до 1000 TPS считается приемлемым. Для высоконагруженных систем это значение может быть значительно выше.

''Latency''  - Низкие значения задержки (например, менее 10 мс) обычно считаются хорошими. Если задержка превышает 100 мс, это может указывать на проблемы с производительностью.

==== Пример использования sysbench. ====

Установка
<code>
sudo apt install sysbench
sysbench --help
</code>
Создание тестовой БД
<code>
sudo -iu postgres createdb testdb2
</code>
Инициализация данных в СУБД через локальное соединение:
<code>
sysbench oltp_common --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=testdb2 --tables=10 --table-size=100000 prepare
</code>
Проведение теста:
Сценарии ''oltp_read_write, oltp_read_only, oltp_update_non_index'', и т.п.
''--threads – число параллельных потоков (клиентов).'' \\
''--time – общее время теста в секундах.''
<code>
sysbench oltp_read_write --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=testdb2 --tables=10 --table-size=100000 --threads=10 --time=300 run
</code>
Очистка:
<code>
sysbench oltp_common --db-driver=pgsql --pgsql-host=127.0.0.1 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres --pgsql-db=testdb2 --tables=10 --table-size=100000 cleanup
</code>

==== Пример использования go-tpc. ====

Установка [[https://github.com/pingcap/go-tpc]]
Подготовка БД для модели аналитических запросов
<code>
go-tpc tpch prepare -d postgres -U postgres -p 'postgres' -D benchmarkh -H 10.2.0.11 -P 5432 --conn-params sslmode=disable
</code>
Запуск эмуляции аналитического запроса
<code>
go-tpc tpch run -d postgres -U postgres -p 'postgres' -D benchmarkh -H 10.2.0.11 -P 5432 --conn-params sslmode=disable
</code>