Мы используем приложение 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 или со стороны выполнения размера пула потоков? Спасибо
У нас есть начальный всплеск в 10 секунд, и мы запрашиваем пики нагрузки до 10 КБ в минуту. Поход продолжается почти 10-15 минут, и около 5% вызовов терпят неудачу, так как у нас есть 10-секундный лимит SLA.




Я думаю, что в первую очередь вам следует попытаться определить узкое место этого потока
Ключевой инструмент для этого - метрики.
Я вижу, что здесь вы используете Hikari, и он сам автоматически предоставляет метрики. Возможно, база данных усердно работает и становится узким местом, в этом случае потребуется относительно много времени, чтобы получить соединение с БД из пула.
Другая возможная проблема может заключаться в том, что фактические запросы к службе несут с собой много контента (возможно, это операция «большой загрузки файла», я не знаю, так ли это, но все же стоит проверить).
Поэтому я предлагаю использовать метрики (встроенные или настраиваемые). Spring boot имеет отличную интеграцию с системами измерения (микрометр для весенней загрузки 2 и метрики dropwizard для весенней загрузки 1.x)
Спасибо Марку за ответ. Это правильно. Я смотрю на показатели, отображаемые микрометром, с помощью / metrics. Также мы просто изменили, чтобы увидеть, как это работает от ограниченной очереди к неограниченной очереди, указав только размер основного пула до 100 и удалив все вышеупомянутые пользовательские настройки минимального размера пула и максимального размера пула. Сейчас у нас есть соединения с БД - 90 * 6 экземпляров. Под нагрузкой используется всего до 300+ подключений. Служба возвращает полезную нагрузку от 1,8 КБ до 2 МБ.
какая у тебя обычная нагрузка? а груз во время похода? сколько времени остается в походе?