Проблема с производительностью Spring BOOT 1.5.6

Проблема с производительностью Spring BOOT 1.5.6

Мы используем приложение REST API на основе Java для весенней загрузки, в котором у нас есть следующие параметры async Spring MVC. При большой нагрузке, когда конечная точка тестируется, конечная точка возвращает ответ API в среднем 30-50 секунд. Это происходит, когда у нас внезапный всплеск продолжительностью 10 минут. Наше идеальное время для 75% процентиля ответа API составляет 1-2 секунды. Ниже приведена конфигурация, мы используем 6 больших экземпляров C5x по 4 ядра на каждый экземпляр.

spring.mvc.async.properties.web.executor.minPoolSize=50
spring.mvc.async.properties.web.executor.maxPoolSize=100
spring.mvc.async.properties.web.executor.maxQueueSize=50
#Hikari Data source properties.
spring.datasource.hikari.minimumIdle=25
spring.datasource.hikari.maximumPoolSize=90
spring.datasource.hikari.idleTimeout=600000

Благодарим за любые предложения по масштабируемости.

Кроме того, мы также определили в нескольких вызовах, что вызовы дБ занимают время, и мы пытаемся выяснить, нужно ли что-то настраивать в запросе, но я думаю, что потоки ждут ответа дБ. Также с исполнителем асинхронного потока с политикой как политика отмены есть ли шанс отклонить любую отправленную задачу? Я ожидаю, что задачи будут поставлены в очередь вместо того, чтобы отклоняться под нагрузкой. Мы отошли от политики callerRuns, чтобы отказаться от политики. Есть ли какие-либо мысли по этому поводу или что-то еще, что требуется со стороны загрузки Spring или со стороны выполнения размера пула потоков? Спасибо

какая у тебя обычная нагрузка? а груз во время похода? сколько времени остается в походе?

Deadpool 08.11.2018 04:04

У нас есть начальный всплеск в 10 секунд, и мы запрашиваем пики нагрузки до 10 КБ в минуту. Поход продолжается почти 10-15 минут, и около 5% вызовов терпят неудачу, так как у нас есть 10-секундный лимит SLA.

Kran 08.11.2018 04:48
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
0
2
251
2

Ответы 2

Я думаю, что в первую очередь вам следует попытаться определить узкое место этого потока

Ключевой инструмент для этого - метрики.

Я вижу, что здесь вы используете Hikari, и он сам автоматически предоставляет метрики. Возможно, база данных усердно работает и становится узким местом, в этом случае потребуется относительно много времени, чтобы получить соединение с БД из пула.

Другая возможная проблема может заключаться в том, что фактические запросы к службе несут с собой много контента (возможно, это операция «большой загрузки файла», я не знаю, так ли это, но все же стоит проверить).

Поэтому я предлагаю использовать метрики (встроенные или настраиваемые). Spring boot имеет отличную интеграцию с системами измерения (микрометр для весенней загрузки 2 и метрики dropwizard для весенней загрузки 1.x)

Спасибо Марку за ответ. Это правильно. Я смотрю на показатели, отображаемые микрометром, с помощью / metrics. Также мы просто изменили, чтобы увидеть, как это работает от ограниченной очереди к неограниченной очереди, указав только размер основного пула до 100 и удалив все вышеупомянутые пользовательские настройки минимального размера пула и максимального размера пула. Сейчас у нас есть соединения с БД - 90 * 6 экземпляров. Под нагрузкой используется всего до 300+ подключений. Служба возвращает полезную нагрузку от 1,8 КБ до 2 МБ.

Другие вопросы по теме