Высокопроизводительное программирование сокетов TCP в .NET C#

Поскольку этот вопрос получает много просмотров, я решил опубликовать «ответ», но технически это не ответ, а мой окончательный вывод на данный момент, поэтому я отмечу его как ответ.

О подходах:

Функции async/await имеют тенденцию создавать ожидаемые асинхронные Tasks, назначенные TaskScheduler среды выполнения dotnet, поэтому имея тысячи одновременных подключений, следовательно, тысячи или чтение /writing запустит тысячи задач. Насколько я знаю, это создает тысячи StateMachine, хранящихся в оперативной памяти, и бесчисленное количество переключений контекста в потоках, которым они назначены, что приводит к очень высокой нагрузке на ЦП. С несколькими соединениями/асинхронными вызовами он лучше сбалансирован, но по мере роста количества ожидаемых задач он замедляется в геометрической прогрессии.

Методы сокета BeginReceive/EndReceive/BeginSend/EndSend технически являются асинхронными методами без ожидаемых задач, но с обратными вызовами в конце вызова, что на самом деле больше оптимизирует многопоточность, но все же ограничения дизайна dotnet этих методов сокета плохо, на мой взгляд, но для простых решений (или ограниченного количества подключений) это путь.

Реализация сокета типа SocketAsyncEventArgs/ReceiveAsync/SendAsync лучше всего подходит для Windows по определенной причине. Он использует Windows IOCP в фоновом режиме для достижения самых быстрых вызовов асинхронных сокетов, а также использует перекрывающийся ввод-вывод и специальный режим сокетов. Это решение является «самым простым» и самым быстрым под Windows. Но под mono/linux он никогда не будет таким быстрым, потому что mono эмулирует Windows IOCP с помощью linux epoll, который на самом деле намного быстрее, чем IOCP, но должен эмулировать IOCP для достижения совместимости с dotnet. , это вызывает некоторые накладные расходы.

О размерах буферов:

Существует бесчисленное множество способов обработки данных в сокетах. Чтение простое, данные приходят, Вы знаете их длину, Вы просто копируете байты из буфера сокета в Ваше приложение и обрабатываете его. Отправка данных немного отличается.

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

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

На стороне отправки размер буфера сокета 1-2-4-8 КБ идеален для большинства случаев, но если вы готовитесь регулярно отправлять большие файлы (более нескольких МБ), то размер буфера 16-32-64 КБ — это то, что вам нужно. Свыше 64 КБ обычно нет смысла переходить.

Но это имеет преимущество только в том случае, если принимающая сторона также имеет относительно большие приемные буферы.

Обычно через интернет-соединения (не по локальной сети) нет смысла получать более 32 КБ, даже 16 КБ идеально.

Превышение размера 4–8 КБ может привести к экспоненциальному увеличению количества вызовов в цикле чтения/записи, что приведет к большой нагрузке на ЦП и медленной обработке данных в приложении.

Уменьшайте размер до 4 КБ, только если вы знаете, что ваши сообщения обычно будут меньше 4 КБ или очень редко превышают 4 КБ.

Мой вывод:

Что касается моих экспериментов, встроенные классы/методы/решения сокетов в dotnet в порядке, но совсем неэффективны. Мои простые тестовые программы Linux C, использующие неблокирующие сокеты, могли превзойти самое быстрое и «высокопроизводительное» решение для сокетов dotnet (SocketAsyncEventArgs).

Это не означает невозможности быстрого программирования сокетов в dotnet, но в Windows мне пришлось реализовать собственную реализацию Windows IOCP путем непосредственной связи с ядром Windows через InteropServices/Marshaling, прямой вызов методов Winsock2, использование множества небезопасных кодов для передачи контекстных структур моих соединений в качестве указателей между моими классами/вызовами, создание собственного ThreadPool, создание потоков обработчика событий ввода-вывода, создание собственного TaskScheduler для ограничения количества одновременных асинхронных вызовов, чтобы избежать бессмысленного переключения контекста.

Это была большая работа с большим количеством исследований, экспериментов и испытаний. Если Вы хотите сделать это самостоятельно, делайте это только в том случае, если Вы действительно считаете, что оно того стоит. Смешивание небезопасного/неуправляемого кода с управляемым кодом — это головная боль, но результат того стоит, потому что с этим решением я мог достичь с моим собственным http-сервером около 36000 HTTP-запросов в секунду по 1-гигабитной локальной сети, в Windows 7, с i7 4790.

Это настолько высокая производительность, которой я никогда не мог достичь со встроенными сокетами dotnet.

При запуске моего сервера dotnet на i9 7900X в Windows 10, подключенном к 4c/8t Intel Atom NAS в Linux через 10-гигабитную локальную сеть, я могу использовать всю пропускную способность (поэтому копируя данные со скоростью 1 ГБ/с), независимо от того, есть ли у меня только 1 или 10000 одновременных подключений.

Моя библиотека сокетов также определяет, работает ли код в Linux, а затем вместо Windows IOCP (очевидно) использует вызовы ядра Linux через InteropServices/Marshalling для создания, использования сокетов и обработки событий сокета напрямую с помощью linux epoll, управляемого максимально увеличить производительность тестовых машин.

Совет по дизайну:

Как оказалось, создать с нуля сетевую библиотеку сложно, особенно такую, которая, скорее всего, будет универсальной для всех целей. Вы должны спроектировать его так, чтобы он имел множество настроек или специально для нужной Вам задачи. Это означает поиск правильных размеров буфера сокета, количества потоков обработки ввода-вывода, количества рабочих потоков, разрешенного количества асинхронных задач, все это должно быть настроено на машину, на которой запущено приложение, и на количество подключений, а также тип данных. Вы хотите передать через сеть. Вот почему встроенные розетки не так хороши, потому что они должны быть универсальными, и они не позволяют вам задавать эти параметры.

В моем случае назначение более двух выделенных потоков для обработки событий ввода-вывода фактически ухудшает общую производительность, поскольку используется только 2 очереди RSS и вызывает большее переключение контекста, чем в идеале.

Выбор неправильных размеров буфера приведет к потере производительности.

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

Различные настройки могут привести к разным результатам производительности на разных машинах и/или операционных системах!

Mono против Dotnet Core:

Поскольку я запрограммировал свою библиотеку сокетов совместимой с FW/Core, я мог протестировать их под Linux с моно и с основной компиляцией. Самое интересное, что я не заметил каких-либо заметных различий в производительности, оба были быстрыми, но, конечно, лучше оставить моно и компилировать в ядре.

Дополнительный совет по повышению эффективности:

Если ваша сетевая карта поддерживает RSS (масштабирование на стороне приема), включите ее в Windows в настройках сетевого устройства в дополнительных свойствах и установите для очереди RSS значение от 1 до максимально возможного/наилучшего для вашей производительности.

Если он поддерживается вашей сетевой картой, то он обычно устанавливается равным 1, это назначает сетевое событие для обработки ядром только одним ядром ЦП. Если вы можете увеличить это количество очередей до более высоких значений, то это распределит сетевые события между большим количеством ядер ЦП и приведет к гораздо более высокой производительности.

В linux это тоже можно настроить, но по-другому, лучше поискать информацию о вашем дистрибутиве linux/драйвере локальной сети.

Надеюсь, мой опыт поможет кому-то из Вас!

У меня такая же проблема. Вам следует изучить: NetCoreServer

Каждый поток в пуле потоков .NET clr может одновременно обрабатывать одну задачу. Таким образом, чтобы обрабатывать больше асинхронных подключений/чтений и т. д., вам необходимо изменить размер пула потоков, используя:

ThreadPool.SetMinThreads(Int32, Int32)

Использование EAP (асинхронный шаблон на основе событий) — это способ работы в Windows. Я бы использовал его и в Linux из-за упомянутых вами проблем и снижения производительности.

Лучше всего использовать порты завершения ввода-вывода в Windows, но они не переносимы.

PS: когда дело доходит до сериализации объектов, настоятельно рекомендуется использовать protobuf-net. Он бинарно сериализует объекты в 10 раз быстрее, чем бинарный сериализатор .NET, а также экономит немного места!