| Вопрос: Реально ли написать мощный сервер на .NET? | Добавлено: 16.11.11 10:06 |
Автор вопроса:  AgentFire | ICQ: 192496851 |
| Ответы | Всего ответов: 28 |
|
Номер ответа: 16 Автор ответа:  Artyom Разработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #16 | Добавлено: 22.11.11 10:05 |
|
Зачем тебе еще варианты если уже озвучен самый оптимальный?
Они есть, но никто в своем уме не станет на них писать сервер под такую нагрузку. Асинхронной достаточно делать часть сетевой подсистемы. Поскольку именно в этом месте можно потенциально неэфективно расходовть ресурсы (большую часть времени занимает ожидание, и есть смысл сделать так, чтоб во время ожидания никакие ресурсы вообще не расходовалось). После того как сообщение получено и на сетевом уровне проверена его целостность, дальнейшую его обработку можно вести в синхронном режиме. Потому что 1) Она будет занимать относительно короткие промежутки времени (например, на получение сообщения потратилось 100мс, а на парсинг потратится 2 мс) 2) Сделать асинхронной ее в принципе невозможно (асинхронность работает только тогда когда речь идет об операциях ввода-вывода) 3) Сделать асинхронной ее возможно, но настолько сложно, что об этом можно забыть (например, работа с СУБД - хотя это и операция ввода-вывода, и ADO .NET имеет на низком уровне функции асихнронного выполнения, почти все системы Data Mapping, в т.ч. LinQ 2 SQL и Entity Framework, не поддерживают эту опцию). |
||
|
Номер ответа: 17 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #17 | Добавлено: 22.11.11 10:27 |
| Не лучше ли будет использовать дальшейшую обработку сообщения все-таки не в одном потоке, а в стольких, сколько ядер в системе? | ||
|
Номер ответа: 18 Автор ответа: EROSВопросов: 58 Ответов: 4255  |
Профиль | | #18 | Добавлено: 22.11.11 10:48 |
|
AgentFire пишет:
Не лучше ли будет использовать дальшейшую обработку сообщения все-таки не в одном потоке, а в стольких, сколько ядер в системе? При условии, что твоя "обработка" хорошо паралелится, в чем я лично сомневаюсь.. Далеко не все задачи имеет смысл паралелить, поскольку потери ресурсов на переключения контекста потоков будут значительно выше потерь при обработке задачи в одном потоке. |
||
|
Номер ответа: 19 Автор ответа: EROSВопросов: 58 Ответов: 4255 |
Профиль | | #19 | Добавлено: 22.11.11 10:53 |
| Кроме того получать данные ты будешь ассинхронно (читать в ,отдельном, уже созданном системой потоке) поэтому не имеет смысла порождать еще один поток для обработки полученного сообщения | ||
|
Номер ответа: 20 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #20 | Добавлено: 22.11.11 11:28 |
| Я нигде не писал что все делать нужно в одном потоке. Кол-во потоков нужно подбирать в зависимости от того что делается. В определенных случаях есть смысл делать кол-во рабочих потоков больше чем кол-во ядер | ||
|
Номер ответа: 21 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #21 | Добавлено: 22.11.11 11:30 |
|
EROS пишет:
При условии, что твоя "обработка" хорошо паралелится, в чем я лично сомневаюсь.. Далеко не все задачи имеет смысл паралелить, поскольку потери ресурсов на переключения контекста потоков будут значительно выше потерь при обработке задачи в одном потоке. Да действительно, как же можно распараллелить обрабокту сообщений, пришедших от разных, возможно, никак не связанных с собой клиентов? О_О |
||
|
Номер ответа: 22 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #22 | Добавлено: 22.11.11 11:36 |
|
EROS пишет:
Далеко не все задачи имеет смысл паралелить, поскольку потери ресурсов на переключения контекста потоков будут значительно выше потерь при обработке задачи в одном потоке. Если рабочие потоки работают в таком режиме, что контексты не переключаются (а это значит что в момент завершения обработки текущего сообщения в очереди уже есть новое, и поток не уходит в режим ожидания нового сообщения), значит сервер уже загружен на 100%, а это фейл. |
||
|
Номер ответа: 23 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #23 | Добавлено: 22.11.11 12:34 |
|
Я имею ввиду следующую картину:
Есть Сетевой модуль, который благополучно принимает сообщения и ставит их в очередь Обработчика на обработку. Этот модуль умеет только принимать сообщения (допустим, в JSON), парсить их, ставить в эту очередь в виде экзепляра класса сообщения и, помимо приёма, он имеет свою собственную очередь таких же сообщений на отправку. Обработчик же имеет потоковую обработку данных, то есть имеет потоков количество, равное кол-ву ядер, и каждый поток, если очередь на обработку не пуста, берет одно задание и выполняет его. Как вам? |
||
|
Номер ответа: 24 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #24 | Добавлено: 22.11.11 13:12 |
|
json неэфективен, поскольку парсинг будет сложным, плюс передается много "мусора" (сравнимо с XML).
Парсинг сообщения должен выполняться после постановки сообщения в очередь для обработки По поводу кол-ва потоков сказано было достаточно, их может быть от 1 до N, где N больше кол-ва ядер. Зависит от того, куда уйдет нагрузка при обработке сообщения, и насколько хорошо параллелится собственно процес обработки одного сообщения. Если сообщения однотипные и обработка эфективно разбивается по всем ядрам, момжно обойтись без параллельной обработки сообщений. Если обработка не параллелится, но нагрузка уходит в основном на CPU, кол-во потоков примерно равно кол-ву ядер. Если при обрабокте вся нагрузка уходит в IO, и ее возможно сделать асинхронно, она делается асинхронно. Если при обрабокте нагрузка уходит в IO, но асинхронной ее не сделать, кол-во потоков делается больше кол-ва ядер, точные значения кол-ва потоков подбирать экспериментально в зависимости от производительности этих IO операций. Если обработка сообщений разнохарактерная (в одних случаях нагрузка уйдет на CPU, в других на ввод-вывод), кол-во потоков должно быть больше кол-ва ядер, значения также экспериментально подбирать. Сделать мало потоков - могут быть простои, сделать много - будет борьба за CPU и переключения контекстов. Впрочем второе не так плохо. Нужно будет имитировать нагрузку, сходную с реальной и подбирать параметры. |
||
|
Номер ответа: 25 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #25 | Добавлено: 22.11.11 15:00 |
| Забукмаркал, спасибо. | ||
|
Номер ответа: 26 Автор ответа: WinandВопросов: 87 Ответов: 2795 |
Web-сайт: Профиль | | #26 | Добавлено: 22.11.11 22:01 |
| Не пойму, в плане чего JSON сложнее и мусорнее XML? Сама разметка ведь наоборот легче | ||
|
Номер ответа: 27 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #27 | Добавлено: 22.11.11 22:18 |
|
Артем же сказал, что мусора "сравнимо с XML". Думаю, что так и есть. С бинарными форматами трудно сравнивать.
С бинарными легко если простая структура пакета. Если что-то сложная - довольно геморно писать построители/парсеры. В телекомах используют интеерсную вещь, называется ASN.1. Я так понял, что там как-то формально описывается структура данных, а потом можно автоматом сгенерить для этого формата парсер. Должно быть удобно. Сам не пользовал 
|
||
|
Номер ответа: 28 Автор ответа: AgentFireICQ: 192496851 Вопросов: 75 Ответов: 3178 |
Профиль | | #28 | Добавлено: 13.04.12 14:37 |
| Ну, я думаю, сгенерить его не так уж и сложно. Если можно перебрать все даненые структуры по порядку. | ||