Опыт написания асинхронного поллинга сетевых устройств

[Slach]

Отличная статья, спасибо

[Slach]

Но не помешают ссылки на gitlab

[makurov]

Читал что это «не по правилам», вот и не стал писать
А вообще https://gitlab.com/mikler/glaber

[linuxoid]

Так-то да, если цель — продать продукт. У вас же чисто инженерное "смотрите, как я сделал". ИМХО, именно для этого и есть Хабр.

[makurov]

Ну черт знает. По честному, там же все равно какой то личный профит в конце, даже если он в том, чтобы «сделать мир лучше».

[event1]

Сколько нужно потоков, чтобы увидеть, что они заработали в течении 30 секунд? — Около 7 тысяч.

Вот этот момент смутил. Неужели 10к потоков, спящих на сокетах, являются проблемой для современного сервера?

[linuxoid]

вообще, спавнить нативные потоки на такую нагрузку — предельно странное решение. Нативные потоки очень дорогие.

[makurov]

У меня нет цифр под рукой, но когда то посчитал, что «дорого» получится. И потоками и форками тем более. Там два очевидных ресурса — память, и ресурсы процессора на переключение контекста.

[linuxoid]

А зачем мы пишем шедулер сами?

Почему не взяли GO? Он прям для этого сделан. Спавним горутину на сокет/устройство. Из коробки шедулинг, параллелизация. Если надо, можно шардировать горизонтально кучей разных способов/библиотек. Нативная сборка, можно собрать, чтоб хоть на ведроиде работать будет...

Куча библиотек сервисного уровня для легкого fallback, short-circuit и т.д.

[makurov]

Очень в тему, спасибо.

Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.

На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.

А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.

А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go