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

#spring-boot #kubernetes #stress-testing #apachebench

#пружинная загрузка #kubernetes #стресс-тестирование #apachebench

Вопрос:

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

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

Я вижу, что мое приложение обрабатывает каждый запрос в течение 10 миллисекунд, согласно журналам. Но результаты теста AB полностью отличаются. Ниже приведены результаты теста 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 запроса, что очень мало. В чем может быть причина? Также каким должен быть способ сохранить датчик жизнеспособности?

В моем приложении установлены следующие свойства.properties:

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

Комментарии:

1. Вы проводите это тестирование из Интернета? Если вы уверены, что ваше приложение работает быстро, тогда вы можете запустить один относительно толстый модуль и выполнить ab-тест изнутри Kubernetes. Таким образом, вы можете понять, является ли это проблемой Kubernetes или нет.

2. Нет, я провожу тест ab внутри самого модуля kubernetes. Приведенный выше результат получен от самого модуля.

3. даже если я запускаю приложение на отдельном компьютере, где запущено только это приложение (без контейнера), и выполняю тест ab локально, результаты почти те же.

4. это означает, что ваше приложение просто работает очень медленно. Попробуйте увеличить ресурсы Kubernetes для этого. Подробнее читайте здесь: kubernetes.io/docs/concepts/configuration /…

5. Как я уже упоминал, я запустил приложение на выделенном сервере с 4 ГБ оперативной памяти и получил почти тот же результат. Что касается приложения, моя конечная точка не взаимодействует ни с какой другой инфраструктурой, и, как уже упоминалось, запрос обрабатывается из приложения в течение 10 мс.