Есть сервер, который должен стримить для всех подключенных к нему клиентов бинарные данные.
Потери допустимы — это что-то типа рил тайм графиков, если выпадет несколько кадров то ничего страшного.
Работает внутри одного сегмента сети.
Количество клиентов может увеличиться как и поток данных.
Сервер на .net core.
Пока что сделано на SignalR, лишь бы запустить первую версию.
По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация.
На что бы вы посоветовали заменить технологию стриминга рил тайм графиков?
Я пока рассматриваю передачу данных по UDP, только дополнительная работа в том, что один пакет данных придется резать на датаграммы. Может, есть что-то менее трудоемкое.
Здравствуйте, Flem1234, Вы писали:
F>Есть сервер, который должен стримить для всех подключенных к нему клиентов бинарные данные. F>Потери допустимы — это что-то типа рил тайм графиков, если выпадет несколько кадров то ничего страшного. F>Работает внутри одного сегмента сети. F>Количество клиентов может увеличиться как и поток данных.
F>Сервер на .net core. F>Пока что сделано на SignalR, лишь бы запустить первую версию. F>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация.
F>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>Я пока рассматриваю передачу данных по UDP, только дополнительная работа в том, что один пакет данных придется резать на датаграммы. Может, есть что-то менее трудоемкое.
Ну если 50/50 то возможно проще будет стриминг ускорить? Например поменять формат данных
Здравствуйте, Jack128, Вы писали:
F>>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация. F>>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков?
J>Ну если 50/50 то возможно проще будет стриминг ускорить? Например поменять формат данных
Да, думаю о том, чтобы подменить сериализатор. В идеале даст 25% ускорения.
F>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>Я пока рассматриваю передачу данных по UDP, только дополнительная работа в том, что один пакет данных придется резать на датаграммы. Может, есть что-то менее трудоемкое.
Здравствуйте, Flem1234, Вы писали:
F>Есть сервер, который должен стримить для всех подключенных к нему клиентов бинарные данные. F>Потери допустимы — это что-то типа рил тайм графиков, если выпадет несколько кадров то ничего страшного. F>Работает внутри одного сегмента сети. F>Количество клиентов может увеличиться как и поток данных.
F>Сервер на .net core. F>Пока что сделано на SignalR, лишь бы запустить первую версию. F>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация.
F>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>Я пока рассматриваю передачу данных по UDP, только дополнительная работа в том, что один пакет данных придется резать на датаграммы. Может, есть что-то менее трудоемкое.
Резать руками не обязательно. Датаграммы "умеют сами себя резать"
Что бы сераилизация не тормозила не используйте сериалайзер, используйте JsonWriter
Здравствуйте, VladCore, Вы писали:
VC>Резать руками не обязательно. Датаграммы "умеют сами себя резать"
Так можно и до TCP дойти.
VC>Что бы сераилизация не тормозила не используйте сериалайзер, используйте JsonWriter
Это шутка? Кто такой JsonWriter? Их нынче штуки 3 приличных. С чего ты вообще взял что он нужен, этот JSON? По моим *личным* наблюдениям при нагрузке любая вменяемая JSON сериализация стремиться к 50%, и это как раз плохо, потому что ее доля должна стремиться к 0.
UPD: Наблюдаемые мной цифры не значат, что она (json сериализация) тормозная или еще чего. Скорее это говорит о характере нагрузки и/или удачи сэмплера. Тем не менее, совет хоть и правильный по замыслу, но в реальности, он звучит как: что бы сериализатор не тормозил, используйте сериализатор, который тормозит. Это извините, дурость.
Здравствуйте, Flem1234, Вы писали:
F>Есть сервер, который должен стримить для всех подключенных к нему клиентов бинарные данные. F>Потери допустимы — это что-то типа рил тайм графиков, если выпадет несколько кадров то ничего страшного. F>Работает внутри одного сегмента сети. F>Количество клиентов может увеличиться как и поток данных.
Используйте multicast
Здравствуйте, Flem1234, Вы писали:
F>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация. F>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>Я пока рассматриваю передачу данных по UDP
Говоришь что тормозит сериализация, но заменить хочешь сетевой протокол? Зачем? У SignalR есть бинарный сериализатор. Нет — можешь protobuf попробовать. Если нужен текстовый формат — есть System.Text.Json, реализованный без перевыделения памяти.
Но вообще при профилировании надо не сколько что времени занимает, а сколько что тратит ресурсы, и прежде всего тот ресурс в который все упирается.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Flem1234, Вы писали:
F>>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация. F>>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>>Я пока рассматриваю передачу данных по UDP
НС>Говоришь что тормозит сериализация, но заменить хочешь сетевой протокол? Зачем? У SignalR есть бинарный сериализатор. Нет — можешь protobuf попробовать. Если нужен текстовый формат — есть System.Text.Json, реализованный без перевыделения памяти.
Если вы про MessagePack, то я его и использую. Не думаю, что протобуф даст значительное ускорение, и то и то бинарные форматы.
Половина тормозов в сериализаторе, половина в других компонентах SignalR. Вот и думаю, на что заменить. А так как мультикаст и отсутствие надежности навевают мысли о UDP, рассматриваю его.
НС>Но вообще при профилировании надо не сколько что времени занимает, а сколько что тратит ресурсы, и прежде всего тот ресурс в который все упирается.
Я назвал цифры со студийного diagnostic tool.
Здравствуйте, Flem1234, Вы писали:
НС>>Но вообще при профилировании надо не сколько что времени занимает, а сколько что тратит ресурсы, и прежде всего тот ресурс в который все упирается. F>Я назвал цифры со студийного diagnostic tool.
Цифры чего? Общего времени выполнения метода, или сколько он процессора съел? Что является критерием производительности для твоей системы — latency или throughput? В какой ресурс упирается — CPU, mem, net? Нет никакой абстрактной производительности, вне контекста советы будут пальцем в небо.
Здравствуйте, Flem1234, Вы писали F>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>Я пока рассматриваю передачу данных по UDP, только дополнительная работа в том, что один пакет данных придется резать на датаграммы. Может, есть что-то менее трудоемкое.
Кэшируй сериализованный пакет. Время сериализации упадёт на много порядков.
Здравствуйте, kov_serg, Вы писали:
_>Используйте multicast
Сильно зависит от топологии сети. Многие внешние маршрутизаторы настроены на дроп мультикастов, так что для интра-сетей обычно мультикаст хорош, а вот внешние сетки — увы.
Возможно, будет полезно попробовать эппловский HLS или аналогичный.
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Здравствуйте, Flem1234, Вы писали:
F>>>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация. F>>>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>>>Я пока рассматриваю передачу данных по UDP
НС>>Говоришь что тормозит сериализация, но заменить хочешь сетевой протокол? Зачем? У SignalR есть бинарный сериализатор. Нет — можешь protobuf попробовать. Если нужен текстовый формат — есть System.Text.Json, реализованный без перевыделения памяти.
F>Если вы про MessagePack, то я его и использую. Не думаю, что протобуф даст значительное ускорение, и то и то бинарные форматы.
Здравствуйте, Danchik, Вы писали:
F>>Если вы про MessagePack, то я его и использую. Не думаю, что протобуф даст значительное ускорение, и то и то бинарные форматы.
D>Выбрось MessagePack и возьми Protobuf или Bond.
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Danchik, Вы писали:
F>>>Если вы про MessagePack, то я его и использую. Не думаю, что протобуф даст значительное ускорение, и то и то бинарные форматы.
D>>Выбрось MessagePack и возьми Protobuf или Bond.
F>А чем они лучше?
Здравствуйте, Flem1234, Вы писали:
F>Есть сервер, который должен стримить для всех подключенных к нему клиентов бинарные данные. F>Потери допустимы — это что-то типа рил тайм графиков, если выпадет несколько кадров то ничего страшного. F>Работает внутри одного сегмента сети. F>Количество клиентов может увеличиться как и поток данных.
F>Сервер на .net core. F>Пока что сделано на SignalR, лишь бы запустить первую версию. F>По результатам профилирования половину времени занимает отправка, из которого еще примерно половина — сериализация.
F>На что бы вы посоветовали заменить технологию стриминга рил тайм графиков? F>Я пока рассматриваю передачу данных по UDP, только дополнительная работа в том, что один пакет данных придется резать на датаграммы. Может, есть что-то менее трудоемкое.
можно посмотреть на протокол SRT (на базе UDP). он сейчас раскручивается в теме live-стриминга,
но на самом деле он универсальный протокол, в репе лежат примеры передачи файлов.
в нём в частности можно указать период в течении которого система будет пытаться переслать пакет.
также есть режим "без потерь" это фактически имитация tcp.
вменяемая статистика (можно знать сколько пакетов потеряно и т.п.), если надо — шифрование. https://github.com/Haivision/srt
