Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Хочу отметить, что получившийся код проигрывает по скорости коду прошлого автора, если параллельно выполняется слишком много запросов. Существует ли способ избежать проверки всех прилетевших событий по-одному в блоке Where? Какой-нибудь GroupBy или Join?
И еще такой вопрос. В какой момент
И еще такой вопрос. В какой момент
SendReceiveUdpAsync подписывается на receiveStream? Такое ощущение, что уже после вызова SendObservable. Не получится ли, что ответ от сервера вдруг прилетит раньше, чем SendReceiveUdpAsync успеет подписаться на входящий поток?
Да, Rx скоростью не блещет. Как минимум в 2 раза медленнее TPL. Но если дело касается IO, то скорость работы малозначительна.
Для High Frequency, увы, не подходит. Но есть RX для CPP, там компилятор успешно инлайнит большинство вызовов.
Избежать проверки всех можно с помощью GroupBy до оператора Connect.
SendReceiveUdpAsync подписывается на receiveStream после SendObservable, это моя ошибка, в которую я постоянно попадаю. Надо использовать Zip, а не SelectMany.
Поправлю пост и код в ближайшее время.
Для High Frequency, увы, не подходит. Но есть RX для CPP, там компилятор успешно инлайнит большинство вызовов.
Избежать проверки всех можно с помощью GroupBy до оператора Connect.
SendReceiveUdpAsync подписывается на receiveStream после SendObservable, это моя ошибка, в которую я постоянно попадаю. Надо использовать Zip, а не SelectMany.
Поправлю пост и код в ближайшее время.
Я говорил не про какие-то два раза, а про отличие в алгоритмической сложности. На тысяче одновременных запросов ваше решение проиграет решению NeoNN в тысячу раз: узким местом является условие Where — точнее, та структура, которую оно строит.
PS GroupBy, как и Join, действительно присутствуют — но они тут не помогут, поскольку негде сохранить накопленный результат. Для того, чтобы воспользоваться ими, надо иметь не набор одиночных запросов — а поток запросов, с которым можно будет слить поток ответов. Но я бы не сказал, что это выходит проще решения без Rx.
PS GroupBy, как и Join, действительно присутствуют — но они тут не помогут, поскольку негде сохранить накопленный результат. Для того, чтобы воспользоваться ими, надо иметь не набор одиночных запросов — а поток запросов, с которым можно будет слить поток ответов. Но я бы не сказал, что это выходит проще решения без Rx.
В реальном случае, когда много параллельных запросов, имеет смысл сделать не один метод
Но для понимания такой код будет слишком сложный.
А если параллельных вызовов нет или мало, например каждый вызов запускается по таймеру, то никаких проблем нет.
SendReceiveUdpAsync, а асинхронную последовательность вызовов Send, сгрупированную по (ip,port) и джоинить на последовательность ответов, сгруппированную по тому же ключу. Внутри используется Dictionary для сопоставления, так что алгоритмическая сложность будет такая же.Но для понимания такой код будет слишком сложный.
А если параллельных вызовов нет или мало, например каждый вызов запускается по таймеру, то никаких проблем нет.
Скажите пожалуйста а Rx подходит для веб-решений(asp .net mvc)? Нет ли противопоказаний?
Практически нет. В вебе все состояние хранится вне веб-сервера. А в RX состояние скрыто внутри подписчиков.
Фактически единственная область применения RX — stateful приложение, которое вынуждена обрабатывать много потоков данных, получаемых по сети, от устройств от пользователя. При этом RX плохо (точнее никак) масштабируется. Вынести часть кода RX на другие серверы штатными способами нельзя.
Фактически единственная область применения RX — stateful приложение, которое вынуждена обрабатывать много потоков данных, получаемых по сети, от устройств от пользователя. При этом RX плохо (точнее никак) масштабируется. Вынести часть кода RX на другие серверы штатными способами нельзя.
Всё зависит от того, как готовить. Вот Netflix, например и веб-сервера и клиентов пишут на Rx (там Rx-Js и Rx-Java, но сути это не меняет). С нагрузками у них всё в порядке.
В целом оно работает, но, конечно, такую мощную и развивающуюся штуку, как asp.net mvc переписывать на Rx — в 95% случаев — это перебор.
В целом оно работает, но, конечно, такую мощную и развивающуюся штуку, как asp.net mvc переписывать на Rx — в 95% случаев — это перебор.
Если на клиенте, то RxJS отлично подходит для многих задач. Особенно в связке с MVVM фреймворками.
На сервере можно применять обычно нет нужды. Отлично подходит, когда есть много асинхронных потоков данных.
На сервере можно применять обычно нет нужды. Отлично подходит, когда есть много асинхронных потоков данных.
Что мешает без RX на эвентах то же самое сделать? А чтобы проще была сортировка сделать с аргументом по хешу. И тогда кто угодно сможет подписаться и получать данные. Правда, обработка будет идти параллельно, если подписчика 2. Но там уж можно как угодно вертеть под свои нужды
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
UDP и C# Reactive Extensions