|
Модераторы: LSD, AntonSaburov |
|
pashadoro |
|
|||
Новичок Профиль Группа: Участник Сообщений: 10 Регистрация: 24.4.2018 Репутация: нет Всего: нет |
Добрый день.
У меня не совсем обычный вопрос/консультация к экспертам. Задание: создать ява клиент/сервер приложение, где клиент асинхронно отсылает на сервер 5 000 000 запросов, дожидается ответов. На этом собственно все ) (на самом деле нет, но это то, что меня особенно интересует.) Так вот, касаемо сетАпа: у меня i5, 4Gb. Java8, Tomcat8. Запускаю клиент/сервер на одной машине. сделал 2 варианта решения задачи. 1) В первом случае использовал Apache HttpClient, Стандартный java ExecutorService. И с 2ух потоков бомбил ендпойнт запросами. Ситуация выглядела так. На момент, когда клиент отослал 1000 000 запросов, сервер в это время обработал около 70 000... Можно представить как забит был Tomcat. в итоге после 300 000 все зачахло (на сервере) 2) Далее попытался решить аналогичную проблему через WebSockets. Использовал SpringBoot. Тут получилось так, что на кждые 10 000 запросов, Tomcat закрывал сессию, в следствии и соединение. В обеих случаят серверная часть сделана на SpringBoot'e. У меня не было иллюзий, что кто то начнет вместе со мной разбирать код по строке Но буду весьма признателен если кто то поделиться опытом/размышлениями на данныю тему. Возможно это вообще не http задача? Возможно стоит полегче слать запросы (например через каждые 5к тормозить на пару секунд) - но что в итоге будет со временем на 5м? Такие варианты как - класер итому подобное не рассматриваю. Нужно решить задачу на обычной машине. С уважением. |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15709 Регистрация: 24.3.2004 Репутация: 209 Всего: 537 |
Да. Тут на самом деле вопрос в TPS который надо выдерживать. Даже в том сетапе который есть, сервер спокойно выдержит 5 000 000 запросов, если TPS будет 1 А вообще в таких задачах обычно используют неблокирующий IO, а если еще добавить реактивные стримы, то должна получится система которая выдерживает очень большое количество запросов. На последнем JPoint как раз был доклад на эту тему: Building scalable, back pressured services with Akka, так к сожалению пока есть только слайды, но зато есть ссылка на код примера: https://github.com/chbatey/akka-streams-flow-control-example -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
pashadoro |
|
|||
Новичок Профиль Группа: Участник Сообщений: 10 Регистрация: 24.4.2018 Репутация: нет Всего: нет |
||||
|
||||
AntonSaburov |
|
|||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: 51 Всего: 118 |
Transactions per second - миллион запросов за секунду скорее всего одна машина просто не потянет. Значит надо понять, сколько запросов за одну секунду должно быть обработано.
|
|||
|
||||
pashadoro |
|
|||
Новичок Профиль Группа: Участник Сообщений: 10 Регистрация: 24.4.2018 Репутация: нет Всего: нет |
Спасибо Антон.
Ребят, хочу консилиум, если Вам не сложно... Конкретные вопросы что родились: 1) Стоит ли копать по хттп? Т.и оптимизировать Томкат итд? 2) 1М в секунду? на хттп это нереально. Без кластеров, лодБалансеров и прочего (на моем сетапе вобщем) Меня вполне 5М за 5минут устроило бы ) В зависимости от вердикта по первому пункту, буду работать далее |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15709 Регистрация: 24.3.2004 Репутация: 209 Всего: 537 |
Я не совсем понял, по постановке задачи есть ограничения на используемый протокол передачи, формат данных и т.д.?
-------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
pashadoro |
|
|||
Новичок Профиль Группа: Участник Сообщений: 10 Регистрация: 24.4.2018 Репутация: нет Всего: нет |
ЛСД, в общем то нет ограничений. Задача: асинхронно отправить с клиента на сервер 5м ордеров, сохранитьв памяти, дожтаться подтверждения что последний сохранен(дождаться на клиенте). После, по одному, точно так же асинхронно их закрыть. (получив ответ что последний закрыт, завершаем замер) Нету чектких структур. Ордер мог бы выглядеть как: ид, сторона, объем. Касаемо протокола - тоже нет огрничений. Но конечно же неплохо бы ограничиться хттп. Это сообщение отредактировал(а) pashadoro - 24.4.2018, 18:57 |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15709 Регистрация: 24.3.2004 Репутация: 209 Всего: 537 |
Ну тогда проще всего использовать какой-то сокетный протокол или HTTP/2.
Если сокеты и блокирующее IO:
С HTTP/2 наверное будет даже проще, там есть асинхронное АПИ, но нужна последняя версия Java. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
pashadoro |
|
|||
Новичок Профиль Группа: Участник Сообщений: 10 Регистрация: 24.4.2018 Репутация: нет Всего: нет |
ЛСД, спасибо за ценнейшие наводки! На сегодня пожалуй достаточно информации. Уже установил 10 джаву(!!!) и 9 томкат. Попробую с хттп 2 поиграть. Но спортивного интереса ради сделаю так же сокетное решение. По этому образцу -> https://medium.com/coderscorner/tale-of-cli...et-a6ef54a74763 Завтра отпишусь, доложу о прогрессе Еще раз спасибо, и хорошего вечера Добавлено через 11 минут и 24 секунды На вскидку вопрос: Например работаю на 10 яве с клиентом по принципу:https://labs.consol.de/development/2017/03/14/getting-started-with-java9-httpclient.html Все четко. Сервер крутится на 9томкате и 10 яве. ЭндПойнты на спринг буте прям из коробки будут эту чудо асинхронностьподерживать? Либо придется сервлет писать? |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15709 Регистрация: 24.3.2004 Репутация: 209 Всего: 537 |
Из коробки врядли, но после настройки должны. Там еще есть тонкости, что браузеры поддерживают HTTP/2 только в связке с TLS, но Java HTTP/2 client по моему не требует TLS. Тут еще момент, надо понять что узкое место сеть или процессор/память. Если сеть то увеличение количества одновременных соединений может помочь. Если процессор/память то лучше делать одно соединение. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
pashadoro |
|
|||
Новичок Профиль Группа: Участник Сообщений: 10 Регистрация: 24.4.2018 Репутация: нет Всего: нет |
Привет!
Я вернулся и уделил время своей задаче ЛСД, спасибо за ответ. Да, я настроил новый сетап под хттп2. Ну очень современно все Ява 10, Томкат9... https://stackoverflow.com/questions/3861270...=google_rich_qa Так настроил его под хттп2. Сервер на спрингБут заработал как есть. Были определенные нюансы, но легко решались. Ощущение - что все это очень сыро пока что. Хотя сам АПИ шикарен. На старый смотреть не хочеться Особенно на клиенте -> http://www.baeldung.com/java-9-http-client Сухой остаток, нет. Не выполняется задача. Шлю ПУСТЫЕ гет запросы асинхронно, на эндпойнт, который возвращает "ОК". 100к и то время занимает. На миллионе модный томкат9 зачах. (Нет, я не стал разбираться был ли РЕАЛьНО задействован хттп2, не стал копать глубоко) Делаю вывод что на хттп, на простеньком домашнем лаптопе - подобная задача невыполнима. |
|||
|
||||
AntonSaburov |
|
|||
Штурман Профиль Группа: Модератор Сообщений: 5658 Регистрация: 2.7.2002 Где: Санкт-Петербург Репутация: 51 Всего: 118 |
А не хочется попробовать сделать совсем простые сетевые клиент и сервер - и пусть они кидают друг другу самые простые слова - Hello Server и Hello Client. Будет хотя бы информация к размышлению.
|
|||
|
||||
rfq |
|
|||
Новичок Профиль Группа: Участник Сообщений: 14 Регистрация: 20.3.2007 Репутация: нет Всего: нет |
Ну так реализуйте backpressure для предотвращения перегрузки сервера. Это такое простое дополнение к протоколу запросов. Суть его в том, что прежде чем послать запрос, клиент запрашивает на это разрешение. Допустим, сервер может хранить необработанными 10000 сообщений. Надо вести учет свободного места для сообщений: пришло сообщение - уменьшаем на 1, обработано и забыто - увеличиваем. Это свободное место делится между клиентами. Клиент подключился - выдаем ему разрешение на 500 сообщений, если есть столько места. Если нет - ставим его запрос в очередь. Когда память освободится, первый запрос из очереди удовлетворяется. Когда клиент исчерпал свою квоту, он делает запрос на следующую порцию, опять запрос либо удовлетворяется, либо ставится в очередь. В общем, получается такой семафор, только распределенный. |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15709 Регистрация: 24.3.2004 Репутация: 209 Всего: 537 |
Это уже все есть из коробки - TCP Window, более того тот пример который я приводил как раз на его основе и работает. TCP Window лучше тем, что работает на уровне TCP стека и не требует никакой поддержки со стороны клиента, не надо ни расширять протокол, ни дорабатывать клиента. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
Правила форума "Java" | |
|
Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux, javastic. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java: Общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |