Си или Go для приложения по обработке сетевого трафика до 1.5М пакетов/с?

Question

[insekt]

Планируется проект по обработке сетевого трафика. Основная суть - взять сырой поток пакетов сетевой карты и извлечь из него различную статистику и метаинформацию. Далее это статистику надо сжать и отправить на сервер. Поток пакетов на входе до 1.5 миллионов пакетов/с.
Дополнительные требования - утилита должна поставляться в виде одного бинарного файла, поддержка x86 и ARM.

Первая мысль, которая меня посетила - это реализация на C/C++, основная причина - добиться высокой производительности даже на слабом/среднем железе.

Несколько знакомых посоветовали приглядеться к Go, мол всем твоим требованиям отвечает, но разработка на Go должна получиться лучше/проще.
Поизучал материалы по Go и не смог сформировать однозначного ответа по Go. Особенно смущает вопрос, не будет ли проигрыша в скорости работы.

Что можно почитать толкового относительно скорости С/C++ vs Go?

Answer 1

[Пума Тайланд]

ну напишите две простых проги для обсчета каких нибудь потоков и сравните скорость

Comments

[d'Ivan]

на примитивных тестах не будет ничего общего с реальностью

[Пума Тайланд]

Роман Мирр: глупости не рассказывайте, это куда более реально, чем задавать вопросы на тостере.

[d'Ivan]

Пума Тайланд: для реальных результатов нужно написать более чем просто "две простых проги".

[Пума Тайланд]

Роман Мирр: что по вашему надо написать то ?
топик стартеру надо одну простую прогу, а тут надо целых две , то есть в два раза больше, чтобы сравнить скорость, каких то супер запросов у него нет, простой парсинг пакетов тут можно вообще сделать как делает кнокд и получить дичайшую производительность, ну а спарсить заголовки дело плевое и все равно писать.

[insekt]

К сожалению, как правильно подметил Роман Мирр , ничего общего с реальностью не получится. Дело не только в IO, но сбор статистики тоже не самый простой получается и ресурсов кушает.
И сделали уже пару прототипов - но никакого очевидного результата не получилось. Прототип же не учитывает множества моментов, из которых какой-нибуть вполне вероятно можем стать узким местом.

[sim3x]

insekt: не хвататет опыта для решения задачи - отказывайся от проекта.
Чем раньше сделаешь - тем лучше для клиента

Answer 2

[d'Ivan]

Выбор в пользу Go:

1. разумный компромис между надёжностью и производительностью. Касательно доводов против из-за производительности по сравнению с Си: всё зависит от структур данных, алгоритмов и их оптимизации для железа.
   
2. простота разработки и отладки
   
3. хорошая поддержка, наличие большого количества проектов и документация
   
4. есть сборка в исполняемые файлы и библиотеки: Go Execution Modes.
   
5. с интеграцией проблем быть не должно - записать файл-бинарник не проблема
   
6. в долгосрочном плане может быть выигрыш при поддержке кода
   

Из недостатков выбора Go:

1. Нужно время на знакомство и эксперименты
   
2. Сразу хорошо написать не получится из-за пункта 1. Возможно, понадобится переписывать некоторые части или всю архитектуру программы пока не получится нужный результат.
   
   

Comments

[sim3x]

GC?

[d'Ivan]

sim3x: насчёт GC полагаю, что это зависит от частоты резервирования памяти. Если она низкая, то ощутимой нагрузки на производительность не будет.

[Den]

пункты 3, 4 относятся и к Си

[twintwin1003]

Роман Мирр "простота разработки и отладки" - насчет разработки ок, а в чем отлаживаете, если не секрет?

Answer 3

[Олег Цилюрик]

Языки программирования: скорость
По качеству сгенерированного нативного кода можно ожидать, что Go будет раз до 2-х (всего!) медленнее, но в плюсах получите а). скорость проектирования + б). возможность очень эффективного распараллеливания работы.
См. также Go конспект.

Comments

[abcyu]

При использовании GCCGO качество сгенерированного кода будет таким же как и для С.

[Олег Цилюрик]

может ... ;-) , но не достигается (проверялось экспериментами), если у вас есть цифры или примеры - давайте обсуждать

[Олег Цилюрик]

abcyu:
Это как с компилятором Clang в сравнении с GCC: авторы Clang уверяют, что в этой реализации есть невиданные перспективы для оптимизации кода, из-за общих подходов проекта LLVM.
А экспериментальная проверка показывает, что тот же код, откомпилированный Clang до несколько раз медленнее, чем после GCC.

[Василий]

ожидать можно чего угодно а вот когда дело доходит до тестов
https://benchmarksgame.alioth.debian.org/u64q/perf...

[abcyu]

Василий: а где там clang?

[Василий]

abcyu: в общемто я отвечал на пост а не коментарий но если вас интересуют тесты по clang то на хабре были тесты habrahabr.ru/post/254121

[Олег Цилюрик]

Василий:
ну и что, что "отвечал на пост"?
там сложно судить, потому что всё зависит от реализации, но Go уступает C в несколько раз по скорости (хотя совершенно непонятно, почему у них C++ должен уступать C ? это у них ... "артефакт реализации"? ... то, что называют "через жопу"? ;-) )

[Василий]

Олег Цилюрик: в коментариях исходников С программы сказано что основано на программе С++ конечно можно посмотреть исходники и поискать разницу в реализации, но сдаётся что тут и компилятор не последнюю роль играет
ЗЫ лично у меня был случай как парочка нопов воткнутых перед условным переходном поднимала скорость программы с тех пор я понял что ничего не понимаю.

[Денис Курбатов]

Олег Цилюрик: На некоторых микротестах - www.phoronix.com/scan.php?page=article&item=gcc-cl... - Clang быстрее GCC, но в общем нет пока. При этом я не единожды читал, что внутри у GCC кромешный ад, и понимают его исходники 2,5 человека.

[abcyu]

Олег Цилюрик: В тех же тестах, что приводил Василий, есть много странного:
https://benchmarksgame.alioth.debian.org/u64q/perf...

1.0 	
Scala #2
	6.77 	223,624 	2080 	20.28 	92% 70% 70% 69%
1.1 	
C++ g++ #3
	7.16 	157,828 	1252 	24.08 	83% 79% 82% 94%
1.2 	
Go #3
	8.14 	259,884 	1399 	29.97 	91% 93% 93% 92%
1.3 	
Clojure #5
	8.81 	360,460 	2852 	22.51 	82% 69% 38% 69%
1.5 	
Rust
	9.89 	155,924 	2027 	26.14 	42% 84% 42% 99%
1.7 	
Java  #7
	11.29 	1,118,288 	1844 	38.66 	83% 97% 82% 82%
1.8 	
Ada 2005 GNAT #2
	11.91 	278,332 	4865 	25.60 	33% 37% 61% 86%
1.8 	
C gcc #7
	12.17 	189,420 	2280 	36.18 	53% 97% 53% 96%

[abcyu]

А, исходя из того, что в описаниях этих текстов указана компиляция с обычным go, а не с gogcc, то еще возможны и другие сюрпризы. ))))

Answer 4

[Oleg Shevelev]

Для обработки сетевого трафика больше подойдёт модуль ядра Linux написанный на Си. Если кто-то умеет такое делать на Golang - дайте знать, с удовольствием послушаю, почитаю на эту тему... Агрегированные же данные (прилетающие от такого модуля) вполне хорошо обрабатывать на Golang (в этом случае можно не заморачиваться одной железкой, а поставить сразу несколько распределив по ним трафик).

P.S. Возможно речь идёт не о linux, но в топике это как-то отдельно не оговаривалось.

Comments

[insekt]

Согласен с вами. Но вот в ядро влезать совсем не хочется, неблагодарное это дело. По ссылке от 31415 есть список готовых и работающих решений для реализации задачи через юзерспэйс.

[Oleg Shevelev]

insekt: юзерспейс по определению медленней для таких операций, потому что происходит как минимум 1 или даже два (не помню точно) обязательных копирований из пространства ядра и обратно.

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

В общем удачи с решением, расскажите что и как делали:)

[insekt]

Посмотрите на проекты pf_ring, snabb switch, netmap - они предназначены для работы с сетевой картой напрямую, пакеты захватываются напрямую из сетевой карты, ядро вообще исключается из процесса и не имеет доступа к сетевой карте.

[Oleg Shevelev]

insekt: интересное замечание, спасибо. Обязательно посмотрю когда буду работать с сетевым стеком поближе. На самом деле иногда про FPGA читаю, но на практике пока нет подходящих проектов.

Answer 5

[Кирилл]

конечно, Си. Потому что придется всю обработку держать в kernel space, возможно, использовать DPDK. Переключения контекста kernel - user сожрут весь CPU на потоке 1.5 Мппс.

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

Answer 6

[Aleksandr Shpak]

На гоу быстрее напишите программу. очевидно что читать ничего не надо чтобы понимать что тормознее работать будет, значительно больше исполняемый файл весить будет.

Comments

[Сергей Протько]

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

[Сергей Протько]

Go достаточно шустрый язык а в рамках этой задачи мы упираемся в работу с I/O. В Go с его горутинами можно легко и просто распаралелить это дело. На Си же файберы и прочее это сложно, а с потоками мы можем потерять чутка производительности за счет переключения контекста.

[Aleksandr Shpak]

Сергей Протько: Кстати да, об этом я не подумал

[insekt]

Сергей Протько: для IO планируется использовать, что-то из этого
https://github.com/ntop/PF_RING
https://github.com/luigirizzo/netmap
чтобы добиться скоростного IO из юзерспэйса.

Не возникнет проблем с интеграицией? Не возникнет ли в этом месте затыка?

[Сергей Протько]

insekt: мм, не могу ответить на этот вопрос пожалуй. 1.5 миллионов пакетов в секунду это довольно много. Я бы на шавем месте исходил из простого, можно быстро написать на Go прототип (в минимальные сроки) и замерять производительность. Если все ок - оставаться с этим. Если нет - смотреть на более низкоуровневые решения.

1.5 миллионов пакетов ... это еще и от размера пакета зависит. Если взять по максимальному MTU (1500) это уже будет порядка 2Gb/s

[Сергей Протько]

Я к тому что 2 гигабита в секунду это много но не очень. Чисто теоритически решения вроде netmap удобны когда у вас надо обрабатывать потоки в 10+ гигабит в секунду. На таких объемах я бы сразу смотрел на Си и на netmap.

[d'Ivan]

Сергей Протько: Всё зависит от структур данных, алгоритмов и их оптимизации. И на Си можно похерить всю производительность.

[abcyu]

Очевидно, что Вы ВООБЩЕ НИЧЕГО НЕ ЗНАЕТЕ о Go.
Большой размер файла - это то, на что спотыкаются НОВИЧКИ даже еще не прочитавшие FAQ.

Размер файла Go - это банальная полная статическая компоновка, возможная и с С/С++, это упрощение deploy, минимум зависимостей от системных библиотек. Это осознанное решение разработчиков языка.

При этом ничто не мешает откомпилировать программу, написанную на Go, с использованием динамической компоновки. Она станет примерно такой же мелкой как и обычная программа на С/С++. И получит те же проблемы с "адом зависимостей", что и типичная программа на С/С++.

Садись, 2.
Иди читай доки, "умный" советчик.

Answer 7

[Alex XYZ]

Я бы предложил "поразмышлял" от обратного - на чём вообще формируется поток с такой скоростью передачи?

Comments

[throughtheether]

я так понимаю, 1.5 миллиона pps - это full-rate для гигабитного интерфейса с минимальной длиной фрейма (если точнее, 1488095 pps)

[insekt]

Да, все верно. Речь идет о максимальной pps на гигабитном интерфейсе.

Answer 8

[cthulhudx]

На C/C++ с использованием Boost asio

Answer 9

[sim3x]

Заказать разработку у специалиста

Answer 10

[Алексей П]

Попробуйте rust-lang

Answer 11

[Денис Курбатов]

Если на LuaJIT можно написать код, генерирующий 35 Mpps на ядро сервера, наверно и на Go так получится. Ещё могут буть полезны эта и эта ссылки.

Comments

[insekt]

Изучал этот вопрос, но больно уж LuaJIT выглядит экзотикой.
За ссылки спасибо.

[abcyu]

insekt: Ответ был иным. Если JIT способен выдать 35Mpps, то уж у нативно компилируемых языков вообще не должно быть проблем на уровне самого языка.
Проблема может быть только на уровне реализации конкретного софта.

Answer 12

[uvelichitel]

Вот только еще не хватало сниффер от руки писать. А что, wireshark из коробки не справляется?

Comments

[insekt]

Для той задачи, которую надо реализовать WS не подходит. Я вообще не любитель изобретать велосипеды.

[uvelichitel]

insekt: у WS исходники открыты, все таки не с чистого листа писать...

[insekt]

Дело в том, что WS не умеет делать ту бизнес логику, которую необходимо.