| Вопрос: Реально ли написать мощный сервер на .NET? | Добавлено: 16.11.11 10:06 |
Автор вопроса:  AgentFire | ICQ: 192496851 |
| Реально ли написать на .NET такой сервер (допустим, под windows 2000 или R2, хз), который бы выдерживал десятки тысяч подключений на рядовом 8 ядернике с 32 гигами оперативки? |
| Ответы | Всего ответов: 28 |
|
Номер ответа: 1 Автор ответа:  Sergey Вопросов: 4 Ответов: 5 |
Профиль | | #1 | Добавлено: 16.11.11 15:06 |
| Как мне кажется - то да. Но это легко проверить. Написать маленький сервер(который только и умел бы подключать клиента) и клиента (котоый только и умел бы подключаться к серверу). Найти 20000 компов и сказать им всем в одно и тоже время подключиться к серваку. Проверку пройдёт (посмотреть загрузку компа) - хорошо, нет - значит проблему нужно искать. Возможно, что и сеть виновата будет при таком большом подключении. Может сеть не выдержать. | ||
|
Номер ответа: 2 Автор ответа: AgentFire ICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #2 | Добавлено: 16.11.11 16:30 |
|
Sergey пишет:
угу спасибо, улыбнуло.
Но это легко проверить: найти 20000 компов и... но меня интересует достоверная информация, которую кто-либо проверял в процессе собственного карьерного роста и не на маленьком сервере, а на крупном, с базой и шлюхами. |
||
|
Номер ответа: 3 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #3 | Добавлено: 16.11.11 22:32 |
|
Реально. Я делал с шлюхами и блекджеком (!)
Причем для этого даже не нужен Windwos 2000 (FAIL!), 8 ядер и 32 гига оперативки. Сервер будет реально держать указанное кол-во подключений (фактически кол-во подключений не будет ограничено со стороны дотнета) одновременно, принимать от них данные и отправлять данные. |
||
|
Номер ответа: 4 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #4 | Добавлено: 17.11.11 05:15 |
|
Нужно понимать, что написание такой системы сопряжено с кучей проблем.
В частности, проблемы многопоточности из теоритических (когда их можно наблюдать только имитируя очень высокую нагрузку, реально не встречающуюся) становятся вполне реальными Необходимо работать в асинхронном режиме (если есть вероятность завершить проект после релиза C# 5, стоит начать делать сразу на нем, так как там асинхронные операции делаются намного проще чем в предыдущих версиях). Серьезно работать над сетевым протоколом (да, мой юный друг, SOAP уже не покатит, так как, передавая 4-байтное число в конверте весом 50 кб, просрешь все полимеры). И вообще на WCF я бы не опирался, так как аналогичная функциональность реализуется тысячей строк кода, над которыми будет полный контроль. |
||
|
Номер ответа: 5 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #5 | Добавлено: 18.11.11 09:53 |
| свой XML протокол? | ||
|
Номер ответа: 6 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #6 | Добавлено: 18.11.11 16:45 |
| ПОд асинхронными подразумеваются BeginXxx и EndXxx ? | ||
|
Номер ответа: 7 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #7 | Добавлено: 19.11.11 02:53 |
|
да, но не BeginInvoke/EndInvoke
Можно свой XML, можно бинарный протокол |
||
|
Номер ответа: 8 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #8 | Добавлено: 19.11.11 12:57 |
| XML всё-таки тяжелый для парсинга. Бинарный будет лучше. Впрочем кто-то еще JSON пользует, тоже вариант. | ||
|
Номер ответа: 9 Автор ответа: BG(Алексей) Вопросов: 26 Ответов: 295 |
Профиль | | #9 | Добавлено: 19.11.11 17:15 |
|
Artyom пишет:
Подробнее плиииииз. Мне интересно почему?
И вообще на WCF я бы не опирался, так как аналогичная функциональность реализуется тысячей строк кода, над которыми будет полный контроль. |
||
|
Номер ответа: 10 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #10 | Добавлено: 20.11.11 18:37 |
|
Почему на WCF бы не опирался?
Я пробовал такой вариант сделать, емнип делал свой транспор и message encoder. Если с транспортом проблем не было, то с енкодером были, потому что вся система даже внутри сильно завязана на SOAP. Мне фактически приходилось свой формат данных преобразовывать в SOAP чтоб WCF мог дальше обрабатывать полученое сообщение. Возможно, можно было уйти глубже и обойти это, но времени на подобные эксперименты уже не было. В результате после попыток сделать на WCF сделал без него. Получил 2-кратное ускорение сетевой части (впрочем небольшое утешение), и полный контроль за процесом. Самой трудоемкой задачей кстати оказался сериализатор/десериализатор сообщений. На тесте выдерживал любое кол-во одновременных подключений (лимит был со стороны ОС, по-моему 32 тысячи с лишним). |
||
|
Номер ответа: 11 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #11 | Добавлено: 21.11.11 09:04 |
| А одновременный обмен данных по хотя бы 3-5 тысячам из этих подключений? | ||
|
Номер ответа: 12 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #12 | Добавлено: 22.11.11 00:51 |
| Если хватит пропускной способности сетевых каналов для приема и передачи данных, оперативной памяти для хранения буферов приема/отправки и программных данных, ресурсов процессора для обрабокти входящих данных и подготовки новых данных для отправки, то возможен. | ||
|
Номер ответа: 13 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #13 | Добавлено: 22.11.11 09:16 |
|
Artyom пишет:
А что тогда?
да, но не BeginInvoke/EndInvoke |
||
|
Номер ответа: 14 Автор ответа: EROSВопросов: 58 Ответов: 4255  |
Профиль | | #14 | Добавлено: 22.11.11 09:34 |
|
AgentFire пишет:
А что тогда? Поскольку речь идет о стримах, то я полагаю BeginRead/EndRead |
||
|
Номер ответа: 15 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #15 | Добавлено: 22.11.11 09:40 |
| А какие есть еще варианты? | ||