| 
 | 
| 
 
В чем смысл Webflux из Spring5 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  questionerОзверинquestioner, очепяталсо, не стрим а сокет. Ну стандартная n+1 проблема в orm заключается чуть чуть в другом - неконтроллируем рост обращений к базе, но итог - да, примерно похожий. В одном случае поток живет долго, а в другом нет - потому что в одном случае данные могут запрашиваться\вставляться\обрабатываться - долго, а в другом - нет. Зависит от объема данных, не знаю, вызываемой хранимки, резалтсета и так далее. Хотите сказать, что бывают какие-то волшебные неблокирующие сокеты? Это ведь в любом случае IO и оно может очень не хило тормозить. спешу напомнить, что работа с устройством физическим - не входит в возможости явы(в основном) и вы как бе - не являетесь системным программистом. Потому что блокирующие сокеты в яве - это контракт, что при вызове системной ф-и на запись, вызов будет ждать окончания записи. А неблокирующие(nio) - это контракт, что при вызове системной ф-ии на запись, никто ничего ждать не будет\может не дожидаться, пытаясь освободить потом как можно быстрее. если же говорить о чтении, то в отдельном потоке будет запрос информаци, в другом - ее получение - неблокирующий сокет. А что там системная ф-ия делает - вопрос уже к реализации в ОС\архитектурному уровню\etc ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 05.06.2019, 13:39 | 
  
  
  
   | 
||
| 
 
В чем смысл Webflux из Spring5 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  Герой днядавайте конкретику, пожалуйста Reactive Streams in Java Concurrency with RxJava, Reactor, and Akka Streams by Adam L. Davis Apress 2019 ISBN-13 (pbk): 978-1-4842-4175-2 ISBN-13 (electronic): 978-1-4842-4176-9 ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 05.06.2019, 14:43 | 
  
  
  
   | 
||
| 
 
В чем смысл Webflux из Spring5 
 | 
|||
|---|---|---|---|
| 
 #18+ 
    
  questionerОзверинquestioner, очепяталсо, не стрим а сокет. Ну стандартная n+1 проблема в orm заключается чуть чуть в другом - неконтроллируем рост обращений к базе, но итог - да, примерно похожий. В одном случае поток живет долго, а в другом нет - потому что в одном случае данные могут запрашиваться\вставляться\обрабатываться - долго, а в другом - нет. Зависит от объема данных, не знаю, вызываемой хранимки, резалтсета и так далее. Хотите сказать, что бывают какие-то волшебные неблокирующие сокеты? Это ведь в любом случае IO и оно может очень не хило тормозить. Протокол бывает неблокирующий, у postgres libpq в оригинале неблокирующий. Т.е. в теории БД может получать по одному сокету подряд запросы с идетификатором и по мере выполнения по тому же сокету отдавать ответы с идентфикатором запроса (т.е отдавать не обязательно в том порядке в котором получила запросы). И БД загружена и сокет загружен. Всем хорошо. В jdbc идентфикатором запроса является поток, запустили запрос в отдельном потоке (сокете) и ждем на него ответ. ...  | 
|||
| 
 : 
 Нравится:
      
  Не нравится:
      
  
   | 
|||
| 05.06.2019, 15:14 | 
  
  
  
   | 
||
| 
 | 

start [/forum/topic.php?fid=59&msg=39822865&tid=2121272]:  | 
    0ms | 
get settings:  | 
    12ms | 
get forum list:  | 
    12ms | 
check forum access:  | 
    3ms | 
check topic access:  | 
    3ms | 
track hit:  | 
    57ms | 
get topic data:  | 
    9ms | 
get forum data:  | 
    3ms | 
get page messages:  | 
    40ms | 
get tp. blocked users:  | 
    1ms | 
| others: | 236ms | 
| total: | 376ms | 

| 0 / 0 | 

    Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
    
    
    «На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
    
    
    ... ля, ля, ля ...