#java #spring-boot #concurrency #jetty #apachebench
#java #spring-загрузка #параллелизм #причал #apachebench
Вопрос:
У меня есть приложение spring boot со встроенным jetty, и его конфигурации таковы: jetty's minThread: 50
jetty's maxThread: 500
jetty's maxQueueSize: 25000 (Я изменил очередь по умолчанию на LinkedBlockingQueue ) Я не менял acceptors и selectors (поскольку я не верю в жесткое кодирование значения)
С приведенной выше конфигурацией я получаю результаты теста jmeter ниже:
- Одновременных пользователей: 60
сводка = 183571 за 00: 01:54 = 1611,9 / с Среднее значение: 36 Мин: 3 Макс: 1062 Ошибка: 0 (0,00%)
- Одновременных пользователей: 75
сводка = 496619 за 00:05:00 = 1654,6 / с Среднее время: 45 мин: 3 Макс: 1169 Ошибка: 0 (0,00%)
Если я увеличу количество одновременных пользователей, я не вижу никаких улучшений. Я хочу увеличить параллелизм. Как этого добиться?
=========================================================================== Обновление 29 марта 2019 года
Я тратил больше усилий на улучшение бизнес-логики. По-прежнему без особых улучшений. Затем я решил разработать один проект hello world spring-boot. т.е.,
spring-boot (1.5.9)
jetty 9.4.15
контроллер rest, у которого есть конечная точка get
приведенный ниже код:
@GetMapping
public String index() {
return "Greetings from Spring Boot!";
}
Затем я попытался выполнить бенчмарк с помощью apachebench
75 одновременных пользователей:
ab -t 120 -n 1000000 -c 75 http://10.93.243.87:9000/home/
Server Software:
Server Hostname: 10.93.243.87
Server Port: 9000
Document Path: /home/
Document Length: 27 bytes
Concurrency Level: 75
Time taken for tests: 37.184 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Total transferred: 143000000 bytes
HTML transferred: 27000000 bytes
Requests per second: 26893.28 [#/sec] (mean)
Time per request: 2.789 [ms] (mean)
Time per request: 0.037 [ms] (mean, across all concurrent requests)
Transfer rate: 3755.61 [Kbytes/sec] received
Connection Times (ms)
min mean[ /-sd] median max
Connect: 0 1 23.5 0 3006
Processing: 0 2 7.8 1 404
Waiting: 0 2 7.8 1 404
Total: 0 3 24.9 2 3007
100 одновременных пользователей:
ab -t 120 -n 1000000 -c 100 http://10.93.243.87:9000/home/
Server Software:
Server Hostname: 10.93.243.87
Server Port: 9000
Document Path: /home/
Document Length: 27 bytes
Concurrency Level: 100
Time taken for tests: 36.708 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Total transferred: 143000000 bytes
HTML transferred: 27000000 bytes
Requests per second: 27241.77 [#/sec] (mean)
Time per request: 3.671 [ms] (mean)
Time per request: 0.037 [ms] (mean, across all concurrent requests)
Transfer rate: 3804.27 [Kbytes/sec] received
Connection Times (ms)
min mean[ /-sd] median max
Connect: 0 2 35.7 1 3007
Processing: 0 2 9.4 1 405
Waiting: 0 2 9.4 1 405
Total: 0 4 37.0 2 3009
500 одновременных пользователей:
ab -t 120 -n 1000000 -c 500 http://10.93.243.87:9000/home/
Server Software:
Server Hostname: 10.93.243.87
Server Port: 9000
Document Path: /home/
Document Length: 27 bytes
Concurrency Level: 500
Time taken for tests: 36.222 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Total transferred: 143000000 bytes
HTML transferred: 27000000 bytes
Requests per second: 27607.83 [#/sec] (mean)
Time per request: 18.111 [ms] (mean)
Time per request: 0.036 [ms] (mean, across all concurrent requests)
Transfer rate: 3855.39 [Kbytes/sec] received
Connection Times (ms)
min mean[ /-sd] median max
Connect: 0 14 126.2 1 7015
Processing: 0 4 22.3 1 811
Waiting: 0 3 22.3 1 810
Total: 0 18 129.2 2 7018
1000 одновременных пользователей:
ab -t 120 -n 1000000 -c 1000 http://10.93.243.87:9000/home/
Server Software:
Server Hostname: 10.93.243.87
Server Port: 9000
Document Path: /home/
Document Length: 27 bytes
Concurrency Level: 1000
Time taken for tests: 36.534 seconds
Complete requests: 1000000
Failed requests: 0
Write errors: 0
Total transferred: 143000000 bytes
HTML transferred: 27000000 bytes
Requests per second: 27372.09 [#/sec] (mean)
Time per request: 36.534 [ms] (mean)
Time per request: 0.037 [ms] (mean, across all concurrent requests)
Transfer rate: 3822.47 [Kbytes/sec] received
Connection Times (ms)
min mean[ /-sd] median max
Connect: 0 30 190.8 1 7015
Processing: 0 6 31.4 2 1613
Waiting: 0 5 31.4 1 1613
Total: 0 36 195.5 2 7018
Из приведенного выше тестового запуска я достиг ~ 27 КБ в секунду с 75 пользователями, но, похоже, увеличение числа пользователей также увеличивает задержку. Также мы можем четко отметить, что время подключения увеличивается.
У меня есть требование, чтобы мое приложение поддерживало 40 тысяч одновременных пользователей (предположим, что все используют собственные отдельные браузеры), и запрос должен быть завершен в течение 250 миллисекунд.
Пожалуйста, помогите мне в этом
Комментарии:
1. Что вы подразумеваете под «увеличением параллелизма»? И почему вы ожидаете повышения производительности приложения при использовании большего количества одновременных пользователей? Поскольку у вас есть 500 принимающих потоков, вы, вероятно, не увидите никаких изменений производительности, связанных с jetty, при менее чем 500 одновременных пользователях,
2. минимум 200 одновременных пользователей могут получить доступ к нашему приложению и параллельно использовать веб-службы, а ожидаемое время отклика должно быть меньше 200 мс. Я мог видеть, что одновременно обрабатывается только от ~ 80 до 100 потоков, независимо от количества одновременных пользователей, установленного в jmeter.
3. Может быть, это связано с вашей настройкой jmeter?
4. Я запустил тест с использованием apachebench. а также добавлено четкое примечание. пожалуйста, взгляните и помогите
Ответ №1:
Вы можете попробовать увеличить или уменьшить количество потоков Jetty, но производительность приложения будет зависеть от логики приложения. Если вашим текущим узким местом является запрос к базе данных, вы вряд ли увидите какие-либо улучшения при настройке HTTP layer, особенно при тестировании по локальной сети.
Найдите узкое место в вашем приложении, попытайтесь улучшить его, а затем измерьте еще раз, чтобы убедиться, что оно лучше. Повторяйте эти три шага до достижения желаемой производительности. Не настраивайте производительность вслепую, это пустая трата времени.
Комментарии:
1. Да, теперь все наши запросы указывают на базу данных. Но я чувствую, что db уже хорошо справляется со своими ограничениями. Я имею в виду, что наше приложение способно выполнять операции с 6000 дб в секунду. Итак, мы хотим масштабировать наше приложение так, чтобы оно обрабатывало не менее 3000 запросов в секунду. Но не знаю, как найти правильный путь. Я новичок в этой настройке производительности.
2. Начните с просмотра этого видео , производительность нелегко измерить.
3. Не могли бы вы, пожалуйста, взглянуть на обновленную информацию и справку