none
Текстовый чат .NET RRS feed

  • Вопрос

  • Здравствуйте!

    Уважаемые знатоки, вопрос касательно архитектуры приложения, а точнее сервера.

    Пишу текстовый чат, даже не так, пишу сайт на сильверлайте, одной из функций которого является реалтайм текстовый чат, вот. Собственно наткнулся на ряд проблем которые уже решил, и уже собрал полностью работоспособную версию как клиента так и сервера. Разработал свои сервисные команды и пр. В общем результатом доволен. Сервер (как собственно и клиент, но это не важно) полностью реализован на асинхронных вызовах, асинхронная отправка пакетов, асинхронное получение. Помимо всего прочего, между клиентом и сервером постоянно "летают" пинги - специальные сервисные пакеты вида <Test - TestOK>, с периодичностью раз в пару секунд и будут передаваться команды (на обновление форума и пр. действия). У сервера всего один поток, просто при подключении клиента создается новый класс "клиент" набивается данными, и работает дальше как самостоятельный организм. Отправка сообщений реализована по схеме - "Клиент-Сервер-Клиент" или, в зависимости от типа сообщения - "Клиент-Сервер-Группа Клиентов", т.е. в конечном счете все сообщения проходят через сервер (как я понял с помощью технологии сильверлайт не получится сделать по схеме "Клиент-Клиент"). Вопрос собственно следующий - какую нагрузку выдержит сервер? Т.е. сколько клиентов онлайн он потянет? Я, на данной стадии ориентируюсь на пиковые ~1000 человек онлайн, и у меня есть опасения что сервер с такой нагрузкой не справится. Что произойдет когда он начнет "буксовать"? Может переделать сервер из асинхронного в многопоточный? Хотя 1000 потоков которые по большей части будут простаивать тоже звучит дико нелогично и  неоптимизировано. В общем проблему я объяснил, потоки или асинхронные вызовы или потянет ли асинхронный сервер 1000 "троллей" в онлайн.


    [URL=http://www.speedtest.net/][IMG]http://www.speedtest.net/result/1458412496.png[/IMG][/URL]

    • Изменено JusteG 5 апреля 2012 г. 16:04
    5 апреля 2012 г. 15:53

Ответы

  • Вот хорошая статья где расписываются несколько вариантов создания сервера и как раз про асинхроннй сказано как самый надежный и быстродействующий (а вот многопоточный на ~1000 начинает захлебываться).

    В общем я думаю эта статья даст вам ответ и может что то еще новое и полезное вычитаете.


    Влюблен в WPF Не пишу на C#


    • Изменено LXGDARKEditor 5 апреля 2012 г. 17:31
    • Помечено в качестве ответа JusteG 5 апреля 2012 г. 17:39
    5 апреля 2012 г. 17:30
    Отвечающий
  • > я ничего не понял из указанного сайта. [...] Целевая платформа Silverlight, язык C#, да будет так.


    на Silverlight вы пишете клиент, но также требуется серверная часть.
    SignalR разработали в Microsoft чтобы облегчить разработку нагруженных сервисов, 
    на сайте есть пример чата. 
    другой пример использования SignalR см. Solving the Shakespeare Million Monkeys Problem in Real-time with Parallelism and SignalR  
      
        

    • Помечено в качестве ответа JusteG 5 апреля 2012 г. 18:18
    5 апреля 2012 г. 18:05

Все ответы

  • > вопрос касательно архитектуры приложения, а точнее сервера. Пишу текстовый чат
     
     
    см. Asynchronous scalable web applications with real-time persistent long-running connections with SignalR
     
      
    5 апреля 2012 г. 16:44
  • Спасибо за внимание, но я ничего не понял из указанного сайта.

    Мне не нужна информация как переделать мой проект. Целевая платформа Silverlight, язык C#, да будет так.

    Вопрос предельно прост, выдержит или нет, если нет, то что произойдет (стеки, очереди вызовов, потеря соединения, бла бла). И что для моих целей и предполагаемых нагрузок лучше, потоки или рассинхронизация.


    [URL=http://www.speedtest.net/][IMG]http://www.speedtest.net/result/1458412496.png[/IMG][/URL]

    • Изменено JusteG 5 апреля 2012 г. 16:52
    5 апреля 2012 г. 16:52
  • Вот хорошая статья где расписываются несколько вариантов создания сервера и как раз про асинхроннй сказано как самый надежный и быстродействующий (а вот многопоточный на ~1000 начинает захлебываться).

    В общем я думаю эта статья даст вам ответ и может что то еще новое и полезное вычитаете.


    Влюблен в WPF Не пишу на C#


    • Изменено LXGDARKEditor 5 апреля 2012 г. 17:31
    • Помечено в качестве ответа JusteG 5 апреля 2012 г. 17:39
    5 апреля 2012 г. 17:30
    Отвечающий
  • Вот, вот, что мне было нужно. Спасибо.

    [URL=http://www.speedtest.net/][IMG]http://www.speedtest.net/result/1458412496.png[/IMG][/URL]

    5 апреля 2012 г. 17:38
  • > я ничего не понял из указанного сайта. [...] Целевая платформа Silverlight, язык C#, да будет так.


    на Silverlight вы пишете клиент, но также требуется серверная часть.
    SignalR разработали в Microsoft чтобы облегчить разработку нагруженных сервисов, 
    на сайте есть пример чата. 
    другой пример использования SignalR см. Solving the Shakespeare Million Monkeys Problem in Real-time with Parallelism and SignalR  
      
        

    • Помечено в качестве ответа JusteG 5 апреля 2012 г. 18:18
    5 апреля 2012 г. 18:05
  • Спасибо, теперь понятно к чему вы меня подталкивали.

    Интересная технология, непременно ознакомлюсь с ней поближе.


    [URL=http://www.speedtest.net/][IMG]http://www.speedtest.net/result/1458412496.png[/IMG][/URL]

    5 апреля 2012 г. 18:18
  • Да, "асинхронный" - конечно слово "модное и красивое", но только от того что оно есть и можно его применять, не значит что, нужно и не всегда это хорошо.

    "Сервер (как собственно и клиент, но это не важно) полностью реализован на асинхронных вызовах, " - нет, как раз таки важно.

    1. Что клиент на асинхронных вызовах сидит это хорошо, там у него ресурсов предостаточно, в подавляющем большинстве случаев подход оправдан, хотя и не всегда, бывают случаи.

    2. Другое дело сервер. Тут использование асихронной обработки запросов не всегда оправдано, почему ? Прежде чем ответить на данный вопрос немножко углубимся в то как ASP.NET обрабатывает запросы. Пришёл запрос, ASP.NET берёт один поток  из пула потоков и начинает обрабатывать запрос используя этот поток. Если запрос обрабатывается синхронно то пока пользовательский код(служба,страница и т.п.) не будет выполнен поток не освободится и результат не буден возвращён клиенту. Если запрос асинхронный то на определённой стадии(месте где реализована асинхронная обработка) поток освобождается и возвращается в пул птоков и готов к обслуживанию других запросов(повышается общая отзывчивость приложения, а количество потоков в пуле дело настраиваемое, но обычно этим управляет сама среда и это наиболле оптимальный вариант за мсключениями). А ваша задача продолжает выполняться уже в отдельном пуле потоков(но тут нужно быть очень осторожным с асинхронными методами и манипулируя потоками, много подводных камне, дабы не получить простаивающие потоки), не связанном с обработкой запросов, и после завершения уже другой доступный поток из пула ASP.NET завершает обработку и возвращает результат клиенту. Отсюда вывод: положительная сторона - больше свободных потоков для обслуживания последующих запросо, отрицательная - накладные расходы, связанные передачей данных и манипуляциями потоков. Исходя из этого, ответ на высше поставленный вопрос - использовать асинхронную обработку запросов для операций занимающих длительное ожидание(вызов удалённых служб, получение больших данных из базы,файлов и т.п). "Помимо всего прочего, между клиентом и сервером постоянно "летают" пинги" - это и есть одни из многочисленных операций асинхронная реализация которых неэффективна.

    "т.е. в конечном счете все сообщения проходят через сервер (как я понял с помощью технологии сильверлайт не получится сделать по схеме "Клиент-Клиент")" - это клиент серверная архитектура, по другому никак.

    "Вопрос собственно следующий - какую нагрузку выдержит сервер? Т.е. сколько клиентов онлайн он потянет? Я, на данной стадии ориентируюсь на пиковые ~1000 человек онлайн" - можно создать нагрузочные тесты в visual studio и тестить, хотя подобные тесты не дают полную объективную картину, но общая картина станет понятной.

    "Что произойдет когда он начнет "буксовать"?" - 503 (Server Unavailable ) отказ в обслуживании клиента.

    "Может переделать сервер из асинхронного в многопоточный?" - а вот смысл этого вопроса никак не понял. Что значит переделать? Если я правильно понял, не сервер переделать, а преписать серверную часть. Как я высше объяснил от того что реализация асинхронная, количество потоков не меняется, даже наоборот увеличивается.

    " В общем проблему я объяснил, потоки или асинхронные вызовы или потянет ли асинхронный сервер 1000 "троллей" в онлайн." - зависит от железа сервака и от того насколько оптимизировано Ваше приложение.

    "Мне не нужна информация как переделать мой проект" - будьте готовы к переменам всегда, иначе какой смысл вопроса.
    • Помечено в качестве ответа Abolmasov Dmitry 5 апреля 2012 г. 21:02
    • Снята пометка об ответе Abolmasov Dmitry 6 апреля 2012 г. 7:36
    5 апреля 2012 г. 20:34
    Модератор
  • немножко углубимся в то как ASP.NET обрабатывает запросы.

    А с чего вы взяли, что автор собирается использовать ASP? Мне как раз показалось, что он пишет самостоятельный сервер.

    А ваша задача продолжает выполняться уже в отдельном пуле потоков(но тут нужно быть очень осторожным с асинхронными методами и манипулируя потоками, много подводных камне, дабы не получить простаивающие потоки)

    Я так понимаю, автор выбирает между синхронным и асинхронным сокетом. Но асинхронный сокет в режиме ожидания НЕ занимает поток. Потому что он работает через IOCP. Это механизм оповещения о завершении асинхронного ввода-вывода, которая реализуется на уровне ядра ОС и не требует отдельного потока.
    5 апреля 2012 г. 21:14
    Отвечающий
  • Мдее... Есть над чем по размыслить, спасибо за развернутый ответ.

    Немного уточнений по тексту:

    "Сервер (как собственно и клиент, но это не важно) полностью реализован на асинхронных вызовах, " - нет, как раз таки важно.

    Я имел в виду, что речь в моем топике пойдет про серверную часть моего приложения. Важно то важно, но не про него речь просто.

    "Можно создать нагрузочные тесты в visual studio и тестить, хотя подобные тесты не дают полную объективную картину, но общая картина станет понятной"

    С этого момента хотелось бы поподробнее, как то пытался создать тест - не получилось и тесты были отложены в "долгий ящик", буду признателен на ссылки с ресурсами в которых раскрывается тема How to по части тестов.

    "503 (Server Unavailable ) отказ в обслуживании клиента."

    Для всех клиентов? Или для тех, у кого сессия самая "старая"? Или для тех, активность которых "вываливает" сервер за рамки? Или для новых?

    "Может переделать сервер из асинхронного в многопоточный?" - а вот смысл этого вопроса никак не понял. Что значит переделать? Если я правильно понял, не сервер переделать, а преписать серверную часть.

    Да, вы поняли правильно, небольшая путаница в формулировке из-за того что серверную часть чата разрабатываю отдельным проектом, отдельно от самого сайта, и проект называется ChatServer как бы банально это не звучало.

    Как я высше объяснил от того что реализация асинхронная, количество потоков не меняется, даже наоборот увеличивается.

    Получается что асинхронные вызовы на деле плодят потоки, по мере необходимости расширяя пул потоков?

    Спасибо за проявленное внимание к моему топику.

    • Изменено JusteG 6 апреля 2012 г. 0:51
    6 апреля 2012 г. 0:42
  • В виде чего вы пишите серверную часть? В виде консольного/winforms приложения или это какой wcf-сервис?


    Для связи [mail]

    6 апреля 2012 г. 7:38
  • Всё высше и ниже перечисленное относится к ASP.NET, а самостоятельная реализация это уже дело другое.

    "А с чего вы взяли, что автор собирается использовать ASP? Мне как раз показалось, что он пишет самостоятельный сервер." - ну тогда флаг ему в руки и респект, ведь создать сервер задача не тривиальная.

    "С этого момента хотелось бы поподробнее, как то пытался создать тест - не получилось и тесты были отложены в "долгий ящик", буду признателен на ссылки с ресурсами в которых раскрывается тема How to по части тестов." - вот, вот хорошая статья, доклады на  techdays относительно производительности IIS и ASP.NET (правда в последнее время сайт переписали, он стал намного быстрее работать, старый сильно тормозил, но в старой версии найти нужное было легче чем сейчас, тегов было побольше и структуризация поудобней), ну и статей в сети по данной теме много, правда на английском.

    "Для всех клиентов? Или для тех, у кого сессия самая "старая"? Или для тех, активность которых "вываливает" сервер за рамки? Или для новых?" - не имеет значения.

    "Получается что асинхронные вызовы на деле плодят потоки, по мере необходимости расширяя пул потоков?" ну плодят слишком громко сказанно, скорее увеличивают количество потоков не из пула обслуживающих запросы, нюанс в том,чтобы эти потоки эффективно отработали и как можно быстрее вернули результат, а не из-за ошибок кода простаивали, увеличивая их общее количество. И 1000 одновременных запросов для ASP.NET это небольшая цифра, главное чтобы код работал, а то из-за неэффективной реализации и 50 запросов могут "уложить" сервер.

    6 апреля 2012 г. 8:55
    Модератор
  • > Мдее... Есть над чем по размыслить
     
     
    и это только верхушка айсберга. для разработки серверной части проще использовать то, что есть в .NET
    см. Self-Host a Web API, HTTP service
     
     
    6 апреля 2012 г. 9:20
  • Сейчас сервер представляет из себя консольное приложение, возможно, в будущем обретет тело в виде винформс.
    9 апреля 2012 г. 3:29