|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Добрый день. Конструкция: Spring Java-backend + React Front. Фронт трогать нельзя. Фронт постоянно долбит бэк REST (JAX-RS) запросом. По заданию, которое изменять нельзя, бэк немедленно отдает данные, если они есть. Если нет, то надо 20 секунд держать запрос в подвешенном состоянии. При стандартном подходе, нить сервера висит 20 секунд ничего полезного не делая. Про производительность в сотни пользователей можно забыть. Вопрос. Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? Это вообще возможно? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 17:04 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче, Дикость какая то. У бэка нет данных но я все равно стою за дверью 20 сек? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 17:43 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
PetroNotC Sharp, это кровавый энтерпрайз. Когда одна команда осчастливила нас этим неработающим решением и устранилась, другая команда пилит фронт и сообщает, что нельзя поменять не поменяв его целиком, а третья сидит и думает как ей дорабатывать напильником вещь. Если б это было не дикостью, все можно было нагуглить в учебниках. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:18 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче, Причем команда? Я логику и код не понял. Если бд тормозит 20 сек, то так и надо писать. А не как аы написали. Что значит "постоянно долбит запросами"? Так инженеры не говорят. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:25 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Щиче, Я логику и код не понял. Если бд тормозит 20 сек, то так и надо писать. БД не тормозит! Ответ, если есть данные - выстреливает мгновенно. А если их нет (это тоже определяется мгновенно) - надо двадцать секунд намеренно растягивать обработку запроса. PetroNotC Sharp Что значит "постоянно долбит запросами"? Так инженеры не говорят. Так и понимать. Запрос отработан - БЕЗ ПАУЗЫ идет другой, аналогичный. Фронт будет спамить сервер запросами насколько хватит ему производительности сети. Именно поэтому сервер растягивает время ответа. Фронт трогать нельзя, WebSocket применить нельзя. Инженеры говорят и матом, если ситуация такая. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:33 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче надо двадцать секунд намеренно растягивать обработку запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:35 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Именно поэтому сервер растягивает время ответа. Есои ответ равен 0,1 сек, то серверу легче сразу отвечать на любой запрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:37 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Щиче надо двадцать секунд намеренно растягивать обработку запроса. Неважно что вы отдадите. Фронт ещё раз попытается выполнить запрос снова. 404 вызовет вывод пользователю ошибки, как любой ответ не 200. Будет 1000 ошибок в секунду. С кодом 200 ошибок не будет, а будет тихое заспамливание бэка. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:38 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче, Давай юз кейс на три ОСМЫСЛЕННЫХ запроса ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:39 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче будет тихое заспамливание бэка. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:40 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Щиче, Давай юз кейс на три ОСМЫСЛЕННЫХ запроса POST запрос с параметром HTTP. 1) Запрос с данными. JSON со списком событий. События представляют собой сериализованные JAVA объекты. Их там максимум штук 5. 2) Запрос без данных - JSON с пустым списком. Случаев только два. Ошибки не предусмотрены. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:42 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче, Запрос без данных не нужен. Юзкейс это действия какие то. А не то что вы написали. Зачем клиенту 100 запросов в сек с событиями? Что за события? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:48 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче, Заспамить сервер очень трудно. Вы не доказали что это произошло. Если заспамили, то сервер начнет тормозить (термин ддосить). Но вы выше говорите что "сервер не тормозит!". Пока ниче не понятно. Может цифры будут? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:53 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Щиче, Запрос без данных не нужен. Юзкейс это действия какие то. А не то что вы написали. Зачем клиенту 100 запросов в сек с событиями? Что за события? А вам зачем конкретные данные? Вопрос был не об этом. Вопрос был о том, как не занимать серверную нить работой, которой все равно нет и при этом заставить фронт ждать ответ определенное время. Это чат. Серверу по Кафке приходит сообщение: сотруднику call-центра пришло сообщение от клиента. Сервер кладет его в очередь и отдает сразу как фронт попросил. Очередь очищается. Пустая очередь - пустой список в ответе. Нормальный чат делается на WebSocket, но нам что дали. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:56 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? java.lang.Thread ? Код: sql 1. 2. 3. 4.
Компилируемость не проверял. Что за странная проблема в "придержать поток на 20 секунд при сотнях пользователей"? А если у вас будут реальные вычисления на двадцать секунд и для сотен пользователей? Вешаться? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:08 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Щиче Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? java.lang.Thread ? Код: sql 1. 2. 3. 4.
Компилируемость не проверял. Что за странная проблема в "придержать поток на 20 секунд при сотнях пользователей"? А если у вас будут реальные вычисления на двадцать секунд и для сотен пользователей? Вешаться? Вот я и не хочу держать поток, но ответ фронту дать через 20 секунд спустя реальной отработки запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:15 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Это чат. Ну наконец то. Раскололся. )))) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:16 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Нормальный чат делается на WebSocket, но нам что дали. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:18 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Серверу по Кафке приходит сообщение: сотруднику call-центра пришло сообщение от клиента. Сервер кладет его в очередь и отдает сразу как фронт попросил. Очередь очищается. Пустая очередь - пустой список в ответе. Тогда можно будет или отдавать список или возвращать отклик-неудачник обратно в очередь и "мариновать" его там нужное время. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:18 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Щиче Серверу по Кафке приходит сообщение: сотруднику call-центра пришло сообщение от клиента. Сервер кладет его в очередь и отдает сразу как фронт попросил. Очередь очищается. Пустая очередь - пустой список в ответе. Тогда можно будет или отдавать список или возвращать отклик-неудачник обратно в очередь и "мариновать" его там нужное время. Можно подробнее, как его там "мариновать нужное время" не останавливая поток? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:21 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Конструкция: Spring Java-backend + React Front. Фронт трогать нельзя. Фронт постоянно долбит бэк REST (JAX-RS) запросом. По заданию, которое изменять нельзя, бэк немедленно отдает данные, если они есть. Если нет, то надо 20 секунд держать запрос в подвешенном состоянии. При стандартном подходе, нить сервера висит 20 секунд ничего полезного не делая. Про производительность в сотни пользователей можно забыть. Вопрос. Как все-таки возможно подержать запрос в 20 секунд, но при этом не блокировать нить бессмысленной работой? Это вообще возможно? Напоминает троттлинг. Тут по смыслу долбящего фронта надо уведомлять статусом типа https://developer.mozilla.org/ru/docs/Web/HTTP/Status/429 Ну и фронт, как хороший лапочка-зайчик должен подождать нужное время Retry-After : x seconds. Это-ж правильный http-клиент? Не? И на бэке не надо делать пауз а наоборот как можно быстрее "отпустить" управление. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:21 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче как не занимать серверную нить работой Но для чата... Не знаю... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:21 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
mayton Напоминает троттлинг. Тут по смыслу долбящего фронта надо уведомлять статусом типа https://developer.mozilla.org/ru/docs/Web/HTTP/Status/429 Ну и фронт, как хороший лапочка-зайчик должен подождать нужное время Retry-After : x seconds. Это-ж правильный http-клиент? Не? И на бэке не надо делать пауз а наоборот как можно быстрее "отпустить" управление. Не знаю насчет правильности. У нас иной раз такая прям высокотехнологичная компания, а иной раз настолько вопиющие ошибки. Надо попробовать. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:27 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче Можно подробнее, как его там "мариновать нужное время" не останавливая поток? Эту очередь разгребают "совсем отдельные" потоки. Если для конкретного запроса есть данные - возвращаем их клиенту. Если данных нет - возвращаем объект обратно в очередь. Для FIFO-очереди это будет "в конец очереди". Если на очередной итерации обнаруживается, что с момента поступления запроса прошло больше заданного интервала ожидания, а данных всё ещё нет - возвращаем пустой список в качестве ответа. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:46 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#18+
Щиче При стандартном подходе, нить сервера висит 20 секунд ничего полезного не делая. Нитей жалко? Добавте. Щиче в сотни пользователей сотня потоков на современной сервере - ни о чем вот уже сотни и тысячи (или десяток докеров по сотне потоков на каждом) - уже кранты хостовой (в случае докера) ОС с переключением потоков. Можно смотреть в сторону NIO. Правда NIO на 10-20% МЕДЛЕННЕЕ (и это правда!) классических сокетов. Но позволяет уменьшить количество потоков, снять нагрузку с диспетчера потоков ОС. Возможно, в качестве алтернативы NIO, при возможности "порезать" задачу, можно использовать нормальный софт для виртуализации и вместо тысячь потоков иметь десяток VM по сотне-тысячи потоков в отдельной VM. Но это теоретически ))). Практически, все вместо нормальных решений используют новомодные из гуана и палок (типа докера) и дохера потоков грузят диспетчер хостовой OS. В этом случае AFAIK без NIO уже сложно. Но повторюсь, это в случае тысячь потоков (в реальном проекте стали мигрировать на NIO при более 6-8 тысячь потоков на хостовой машине) и скорости это НЕ добавляет. Даже, повторюсь, NIO медленнее на 10-20%. AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:51 |
|
Асинхронное выполнение запросов
|
|||
---|---|---|---|
#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?all=1&fid=59&tid=2120308]: |
0ms |
get settings: |
16ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
34ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
608ms |
get tp. blocked users: |
0ms |
others: | 349ms |
total: | 1018ms |
0 / 0 |