Как и на чем лучше сделать архитектуру сервера, который держит соединение с клиентом?
Моему клиенту потребовалось одно десктопное приложение на шарпе, которое получает и обновляет у себя данные от json api раз в секунду. Я считаю, что это очень будет тяжело и для приложения и для апи, когда будет 1000 клиентов, и надо сделать серверную прослойку, которая будет с одной стороны потреблять апи и обновлять все у себя, а с другой стороны держать постоянное соединение с каждым клиентом и отправлять им самостоятельно только дифф по данным. Серверное ПО компания тоже обычно пишет на шарпе. В связи с этим очень эотелось бы услышать мнения:
1. Прав ли я в необходимости серверной прослойки?
2. На мой взгляд, для этого лучше использовать приложение на Go или Node.js, так ли это или неважно и на шарпе тоже будет нормально?
3. Если писать на шарпе, какой подход / компоненты лучше использовать, чтобы держать соединение и отправлять данные клиенту?
Заранее спасибо.
1. 1000 клиентов с обновлением раз в секунду - это 17 обменов в секунду. Смешная нагрузка. Низкая. У меня подтверждено замерами 5000 обменов в секунду на VDS с 512 М оперативы и одним ядром.
2. Лучше использовать то, что вы лучше всего умеете использовать. Для этой задачи - они все равны.
1. Откуда взялось 17, если каждый из 1000 обменивается раз в секунду? И каждому надо отдать целый json файл с Х строками раз в секунду, против 1-2 строк и только по факту реального появления.
2. С точки зрения умения всё равно что использовать, я больше завязан на корпоративные заморочки. Однако, для конструктивной дискуссии: на каждого клиента надо создать поток, что может быть тяжеловесно для шарпа, в отличие от гоу, и на каждого надо держать соединение, что лучше (насколько я знаю) умеет Node.js. Это не так?
Моему клиенту потребовалось одно десктопное приложение на шарпе, которое получает и обновляет у себя данные от json api раз в секунду. Я считаю, что это очень будет тяжело и для приложения и для апи, когда будет 1000 клиентов
Ну да, ошибся.
1000 раз в секунду - не высокая нагрузка также.
И каждому надо отдать целый json файл с Х строками раз в секунду, против 1-2 строк и только по факту реального появления.
Отдельный сервер тут ничего не решает.
Производительность будет так же. Что с цельным приложением, что с промежуточным сервером
Кроме, возможно, простого удобства для программирования.
Например, я реализовал недавно отдельный сервер для сходной задачи - так как в приложении мне было неудобно обрабатывать многопоточно запросы клиентов из-за особенностей архитектуры приложения.
Но за это придется платить усложнение общей схемы работы, усложнение администрирования.
Мне пришлось админа 3 раза пнуть чтобы он не забыл включить этот доп. сервер в резервное копирование.
И все равно, когда админ переехал на новое железо - он забыл взять мой доп. сервер с собой. Хорошо, что было в бэкапах.
С точки зрения умения всё равно что использовать, я больше завязан на корпоративные заморочки. Однако, для конструктивной дискуссии: на каждого клиента надо создать поток, что может быть тяжеловесно для шарпа, в отличие от гоу, и на каждого надо держать соединение, что лучше (насколько я знаю) умеет Node.js. Это не так?
Я бы выбрал Go.
Просто потому что лучше его знаю.
Вам виднее что выбирать.
---------------------------
У C# нет никаких описанных вами ограничений.
Если вам не нравится многопоточность C#, то можно сделать мультиплексированием - то есть один поток обрабатывать множество сокетов, просто перебирая сокеты последовательно (читая/записывая в буфер, а буфер заполняется независимо от потока.
---------------------------
Если это действительно так:
С точки зрения умения всё равно что использовать
То вы уже знаете ответ на свой вопрос.
---------------------------
что лучше (насколько я знаю) умеет Node.js.
Это легенды.
Node.JS первым научился использовать ресурсоэкономный websocket вместо long polling.
В те времена он действительно был лучше прочих.
Но это было уже очень и очень много лет тому назад.
Сейчас с веб-сокетами умеют хорошо работать все современные инструменты для веба.
--------------------------------------
на каждого клиента надо создать поток, что может быть тяжеловесно для шарпа, в отличие от гоу
Если у вас простой протокол взаимодействия - пришел клиент, сразу получил данные - то можно все легко сделать в одном потоке даже, если вам не нравится многопоточность.
Если у вас какой то сложный протокол взаимодействия, то вам больше понравится именно легковесные потоки. Например, у меня упомянутом написанном на Go сервере, которое обрабатывало 5000 запросов в секунду нужно было следить за переполнением буфера для каждого соединения (если клиент долго не обращался за данными) что привело к приличному ветвлению внутри программы для обработки каждого соединения.
Кроме того:
Вам же известны метрики: 1000 клиентов. Просто создайте на C# эту тысячу потоков в виде теста и посмотрите тяжело это для него или нет.
Спасибо за развёрнутый ответ, ситуация примерно ясна. По всей видимости, действительно будем пробовать-тестировать производительность. Как я сейчас понял из общения с человеком, там больше проблема в том что именно апи тяжело принять даже 100 запросов.
1. Мой сервер Дистанционной системы проектирования (написанный на C#) с поддержкой постоянного соединения с каждым клиентом, отправкой файлов после каждого сохранения держит не напрягаясь 10000 клиентов онлайн.
Характеристики сервера: Xeon 12 ядер, 64гига оперативы, WinServer 2012R2
2. Будет нормально работать на C# вполне, в плане серверных приложений он не уступает никому.
3. WCF с привязкой NetTcpBinding Duplex
huwesu: задумайтесь, чем инициация соединения по HTTP отличается от классического сокетного соединения?
Плюс, если клиент будет находиться за проксей, то использование любого нестандартного метода коммуникации между клиентом и сервером вызовет кучу проблем.
Опять же стандартные протоколы обеспечат возможность легкого расширения системы и интеграции других составляющих. Например, если вдруг нужно будет написать какой-нибудь веб-индикатор с обновлением в режиме реального времени это займет один день, а с вашим подходом прийдется все делать заново с нуля.
Опять же стандартные протоколы обеспечат возможность легкого расширения системы и интеграции других составляющих. Например, если вдруг нужно будет написать какой-нибудь веб-индикатор с обновлением в режиме реального времени это займет один день, а с вашим подходом прийдется все делать заново с нуля
Почему бы тогда вообще не взять за основу Protobuf?
;)))))
Простой
