датчик живучести не работает с конечной точкой привода во время стресс-тестирования/нагрузочного тестирования?

Я делаю ab-тестирование своего приложения, где я отправляю 3000 одновременных запросов и всего 10000 запросов. Мое приложение представляет собой приложение с весенней загрузкой с приводом, и я использую kubernetes и докер для контейнеризации. Во время тестирования мои конечные точки привода занимают больше времени, чем ожидалось, из-за этого мои модули перезагружаются, и запросы начинают отказывать.

Теперь я остановил проверку живучести, и во время теста, если я вручную нажму на конечную точку привода, я вижу, что ответ занимает много времени, а иногда он даже не возвращает результат и просто зависает.

Я вижу, что каждый запрос обслуживается моим приложением в течение 10 миллисекунд, согласно журналам. А вот результаты АБ-теста совсем другие. Ниже приведены результаты теста AB:

Concurrency Level:      3000
Time taken for tests:   874.973 seconds
Complete requests:      10000
Failed requests:        6
   (Connect: 0, Receive: 0, Length: 6, Exceptions: 0)
Non-2xx responses:      4
Total transferred:      1210342 bytes
Total body sent:        4950000
HTML transferred:       20580 bytes
Requests per second:    11.43 [#/sec] (mean)
Time per request:       262491.958 [ms] (mean)
Time per request:       87.497 [ms] (mean, across all concurrent requests)
Transfer rate:          1.35 [Kbytes/sec] received
                        5.52 kb/s sent
                        6.88 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  372 772.5      0    3051
Processing:  1152 226664 145414.1 188502  867403
Waiting:     1150 226682 145404.6 188523  867402
Total:       2171 227036 145372.2 188792  868447

Percentage of the requests served within a certain time (ms)
  50%  188792
  66%  249585
  75%  295993
  80%  330934
  90%  427890
  95%  516809
  98%  635143
  99%  716399
 100%  868447 (longest request)

Не могу понять это поведение, так как оно показывает, что в секунду обслуживается примерно 11,43 запроса, что очень мало. Что может быть причиной ? Также каким должен быть способ сохранить живость?

У меня есть следующие свойства, установленные в моем application.properties:

server.tomcat.max-connections=10000
server.tomcat.max-threads=2000

person Lakshya Garg    schedule 25.04.2019    source источник
comment
Вы делаете это тестирование из Интернета? Если вы уверены, что ваше приложение работает быстро, вы можете запустить один относительно толстый pod и запустить ab-тест изнутри Kubernetes. Так вы сможете понять, проблема ли это в Kubernetes или нет.   -  person Vasili Angapov    schedule 25.04.2019
comment
Нет, я провожу тест на пресс внутри самого модуля kubernetes. Вышеприведенный результат получен из самого модуля.   -  person Lakshya Garg    schedule 25.04.2019
comment
даже если я запускаю приложение на отдельной машине, где запускается только это приложение (не в контейнере), и выполняю тест ab локально, результаты почти такие же.   -  person Lakshya Garg    schedule 25.04.2019
comment
это означает, что ваше приложение просто очень медленное. Попробуйте увеличить для этого ресурсы Kubernetes. Подробнее читайте здесь: kubernetes.io/docs/concepts/configuration/< /а>   -  person Vasili Angapov    schedule 25.04.2019
comment
Как я уже упоминал, я запускал приложение на выделенном сервере с 4 ГБ оперативной памяти и получил почти такой же результат. Понимание среди приложений, моя конечная точка не взаимодействует с какой-либо другой инфраструктурой, и, как уже упоминалось, запрос обслуживается приложением в течение 10 мс.   -  person Lakshya Garg    schedule 25.04.2019
comment
@Hanx, этот вопрос касается поведения во время нагрузочного теста, а не свойства max-connections. max-connections и max-threads - это просто информация, которую я предоставил, если это необходимо.   -  person Lakshya Garg    schedule 18.06.2019
comment
Как упоминалось в сообщениях выше, Те же результаты для неконтейнерной среды. Пожалуйста, рассмотрите разные конфигурации приложений и tomcat и разные зонды живости: команда, запрос http или сокет tcp и параметры готовности. Кроме того, проверка живости остановлена, и во время теста... я вижу, что ответ занимает много времени.... он даже не возвращает результат и просто зависает Согласно < href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/" rel="nofollow noreferrer">документация. это ожидаемое поведение.   -  person Mark    schedule 18.06.2019