|
|
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Щиче Вопрос. Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? Это вообще возможно? Реактивщина, например идите в Kotlin и используйте ktor и корутины. В Спринге тоже что-то такое есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 09:22 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Щиче, Я не услышал. Что КОНКРЕТНО происходит если убрать sleep 20 сек из сервлета и не тормозить ответ клиенту? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 09:52 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev Нитей жалко? Добавте. А вы представьте, что у вас тысячи операторов и миллионы (в прямом смысле) клиентов в день. А вы предлагаете добавить нитей. Конечно, это решается добавлением балансировки. Но может просто сделать по нормальному? Насколько выйдет. Для того, чтобы ни у кого не возникало мыслей, а что тут вообще решать объясню: чат для поддержки клиентов конторы охватывающей всю Россию и несколько сопредельных стран. Т.е. много, очень много клиентов и много операторов call-центра. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 10:15 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Щиче Конструкция: Spring Java-backend + React Front. Фронт трогать нельзя. Фронт постоянно долбит бэк REST (JAX-RS) запросом. По заданию, которое изменять нельзя, бэк немедленно отдает данные, если они есть. Если нет, то надо 20 секунд держать запрос в подвешенном состоянии. При стандартном подходе, нить сервера висит 20 секунд ничего полезного не делая. Про производительность в сотни пользователей можно забыть. Вопрос. Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? Это вообще возможно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 10:43 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Щиче Конечно, это решается добавлением балансировки. Но может просто сделать по нормальному? вы теорию откройте. Балансировка - это горизонтальное масштабирование. Это основа веб. Вы это масштабирование как то противопоставляете. Уничижительно))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 12:20 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Как уже сказали для асинхронщины + spring два самых простых решения: 1) Асинхронные сервлеты (должны на автомате подниматься, если из контроллера возвращать CompletableFuture) 2) WebFlux (или какая-нибудь другая реактовщина) Второй вариант заставит переписывать кучу кода. Первый вариант вроде бы проще, но тут к сожалению тоже надо будет понимать, что делаешь и какие блокировки есть в коде. Ибо если там Thread.sleep(20)/блокирущие коннект или что-то типа, то будет все довольно печально P.S ну и ваще странно, что в 21 века надо писать какой-то чат на лонгпуллингах, а не использовать какое-нибудь готовое решение, без написания кода вообще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 14:00 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Щиче Leonid Kudryavtsev Нитей жалко? Добавте. А вы представьте, что у вас тысячи операторов и миллионы (в прямом смысле) клиентов в день. А вы предлагаете добавить нитей. Конечно, это решается добавлением балансировки. Но может просто сделать по нормальному? Насколько выйдет. Представил, если БД оракл драйвер только синхронный (для остальных тоже, есть там конечно ассинхронные уже для postgres точно, но статус непонятный можно ли в продакт брать). Срочно сесть и начать писать ассинхронный драйвер или перевести все на монгу или добавить нитей. Ну и навскидку проект ассихронных jdbc драйверов похоронил oracle, в пользу project loom, говорят ждите - (ждем). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.11.2021, 17:09 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Спасибо за советы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.11.2021, 15:56 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
mayton Напоминает троттлинг. Тут по смыслу долбящего фронта надо уведомлять статусом типа https://developer.mozilla.org/ru/docs/Web/HTTP/Status/429 Ну и фронт, как хороший лапочка-зайчик должен подождать нужное время Retry-After : x seconds. Это-ж правильный http-клиент? Не? И на бэке не надо делать пауз а наоборот как можно быстрее "отпустить" управление. Два чая этому господину. Правильный термин это rate limiting и реализуется отправкой корректного статуса и обработкой на клиенте. Совет собрать яйца в кулак и переписать фронт от Станислава - тоже правильный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2021, 16:55 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Щиче Вопрос. Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? Это вообще возможно? это называется buzy spin - пускай по циклу чтобы не блокировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2021, 21:49 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
localhost8080 Щиче Вопрос. Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? Это вообще возможно? это называется buzy spin - пускай по циклу чтобы не блокировать Слышал звон... Но молодец, пытаешься копать глубоко, пока просто в силу отсутствия опыта не получается, но главное что желание есть Busy spin это и есть бессмысленная работа, которую ТС хочет избежать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2021, 23:29 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov Щиче Можно подробнее, как его там "мариновать нужное время" не останавливая поток? Эту очередь разгребают "совсем отдельные" потоки. Если для конкретного запроса есть данные - возвращаем их клиенту. Если данных нет - возвращаем объект обратно в очередь. Для FIFO-очереди это будет "в конец очереди". Если на очередной итерации обнаруживается, что с момента поступления запроса прошло больше заданного интервала ожидания, а данных всё ещё нет - возвращаем пустой список в качестве ответа. FIFO - это "честная" очередь - уж если ты первый, так я - извинюсь и подвинусь. Под заявленную пожелалку больше какая-то разновидность "очереди с приоритетом" подходит, имхо. Поставить в конец FIFO, значит обречь себя на неизвестное время извлечения. То ли процесс зациклится на повторном помещении единственного сообщения в очередь, то ли в обработку оно придет много позже положенных 20 секунд - сие функция длины очереди. Вариант очереди с приоритетом позволит не просто поставить в очередь, а поставить в порядке планового времени ожидаемого ответа. Кроме того, по ситуации, ее можно сделать двухструйной, где в одной струе - "нормальные ответы", а в другой отложенные, которые очередь не отдает до наступления назначенного им момента. В последнем случае на высоких нагрузках может потребоваться дополнительное правило, управляющее старшинством обработки "струй" в зависимости от их текущего размера, например. как-то так мне кажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2021, 01:08 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
Да тут обычные зеленые потоки нужны, может даже в java допилят их когда-то Как там проект LOOM, жив еще? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2021, 01:10 |
|
||
|
Асинхронное выполнение запросов
|
|||
|---|---|---|---|
|
#18+
booby Поставить в конец FIFO, значит обречь себя на неизвестное время извлечения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2021, 09:09 |
|
||
|
|
start [/forum/topic.php?fid=59&msg=40113275&tid=2120308]: |
0ms |
get settings: |
28ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
315ms |
get tp. blocked users: |
1ms |
| others: | 388ms |
| total: | 812ms |
| 0 / 0 |
