HikariCP - нагрузочное тестирование снижает производительность - PullRequest
0 голосов
/ 06 июня 2018

Я использую HikariCP в своем приложении для весенней загрузки, и я начинаю делать некоторые нагрузочные тесты с JMeter.

Я заметил, что при первом запуске моих тестов все идет хорошо, и каждый запрос занимаетпримерно 30 мс или около того.

Но каждый раз, когда я запускаю свои тесты снова, для того же экземпляра приложения, время отклика ухудшается, пока не замерзнет, ​​и я не получу много

Caused by: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30019ms.
    at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:583)
    at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:186)
    at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:145)
    at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:112)
    at sun.reflect.GeneratedMethodAccessor501.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at net.bull.javamelody.JdbcWrapper$3.invoke(JdbcWrapper.java:805)
    at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286)
    at com.sun.proxy.$Proxy102.getConnection(Unknown Source)
    at org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin(DataSourceTransactionManager.java:246)
    ... 108 common frames omitted

Я даже оставил приложение бездействующим на один день и попробовал снова, но тесты показывают снижение производительности и те же ошибки.

Только если я закрою приложение, оно сможет снова запустить мои тесты, но только одна загрузка (1200+ запросы).

Когда я разрабатывал тесты, я запускал свое локальное приложение с базой данных H2 и не замечал какой-либо деградации, пока не развернул свое приложение на сервере, на котором работает postgresql.

Таким образом, чтобы убрать эту переменную из того, как я оставил JMeter запущенным в моем локальном приложении H2, показалось ухудшение.

Вот тестовый сценарий, который я запустил на своем компьютере.ocal app (база данных H2), с размером опроса HikariCP по умолчанию (10), используя 10 потоков.Мне удается выполнить более 25 000 запросов до того, как приложение перестает отвечать.

Я составил запросы:

0-50005000-1000010000-1500015000-2000020000-25000

Кроме того, тесты состоят из запроса к Spring Boot @RestController.

Мой контроллер вызывает службу с @Transactional в начале (я называю некоторые устаревшие API, для которых требуется транзакция, поэтомуЯ открываю его сразу).

Итак, допустим, у меня есть тесты, которые 10 раз параллельно запрашивают эту конечную точку.Допустим также, что в моем коде могут быть другие точки, помеченные @Transactional.Был бы достаточен размер опроса 10?

Кроме того, достаточно ли какого-либо размера опроса, несмотря на низкую производительность, или это нормально для такого сценария, когда опрос просто слишком занят и "locks "?

Я также пытался увеличить размер опроса до 50, но проблема сохраняется.Он приближается к предыдущим 25000 запросам из предыдущих тестов (с размером 10 опросов) и завершается с ошибками, как указано ранее.

Ответы [ 2 ]

0 голосов
/ 12 июня 2018

Итак, в конце концов, это была утечка памяти.Ничего общего с HikariCP.

У нас есть несколько скриптов Groovy, использующих @Memoized с некоторыми очень плохими ключами кеша (огромными объектами), и этот кеш продолжал увеличиваться, пока не осталось свободной памяти.

0 голосов
/ 06 июня 2018

HikariCP предлагает использовать небольшой пул постоянного размера, насыщенный потоками, ожидающими соединения. Согласно документам рекомендуемый размер пула :

соединений = ((core_count * 2) +ffective_spindle_count)

Формула, которая довольно хорошо сохраниласьМногие годы измеряются тем, что для оптимальной пропускной способности число активных соединений должно быть где-то рядом ((core_count * 2) +ffective_spindle_count).В число ядер не должны включаться потоки HT, даже если включена гиперпоточность.Эффективное число шпинделей равно нулю, если активный набор данных полностью кэширован, и приближается к фактическому количеству шпинделей при падении частоты попаданий в кэш.... До сих пор не проводился анализ того, насколько хорошо формула работает с твердотельными накопителями.

Н2 в памяти с небольшим набором данных будет быстрее, чем автономная база данных, работающая на другойсервер.Даже если вы работаете в одном и том же центре обработки данных, обход между серверами обычно составляет около 0,5-1 мс.

Сначала попытайтесь найти текущее узкое место.Если на сервере приложений не хватает процессора, то проблема в другом месте, например, в сервере баз данных.Если вы не можете понять, где находится текущее узкое место, вы можете оптимизировать в неправильном месте.

...