Comments 10
Отличная статья, спасибо
Но не помешают ссылки на gitlab
Читал что это «не по правилам», вот и не стал писать
А вообще https://gitlab.com/mikler/glaber
А вообще https://gitlab.com/mikler/glaber
Сколько нужно потоков, чтобы увидеть, что они заработали в течении 30 секунд? — Около 7 тысяч.Вот этот момент смутил. Неужели 10к потоков, спящих на сокетах, являются проблемой для современного сервера?
вообще, спавнить нативные потоки на такую нагрузку — предельно странное решение. Нативные потоки очень дорогие.
У меня нет цифр под рукой, но когда то посчитал, что «дорого» получится. И потоками и форками тем более. Там два очевидных ресурса — память, и ресурсы процессора на переключение контекста.
А зачем мы пишем шедулер сами?
Почему не взяли GO? Он прям для этого сделан. Спавним горутину на сокет/устройство. Из коробки шедулинг, параллелизация. Если надо, можно шардировать горизонтально кучей разных способов/библиотек. Нативная сборка, можно собрать, чтоб хоть на ведроиде работать будет...
Куча библиотек сервисного уровня для легкого fallback, short-circuit и т.д.
Очень в тему, спасибо.
Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.
На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.
А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.
А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go
Да, я бы сказал так — тогда был выбран такой путь, сейчас решение расширения функциональности на Go мне кажется самым верным и так оно и делается для нового функционала. Но я этот путь чуть позже асинхронного SNMP осознал, поэтому там осталось на С.
На самом деле на Go я одновременно с реализацией 4 прорабатывал. Но там копились разные мелочи — то мибы не транслируются, то поддержки v3 нет, то что то еще. В общем, учитывая опыт в С и отсутсвие такового в Go, решил в какой то момент оставить реализацию на С.
А так то было бы очень интересно сравнить ресурсы на Go и на С (память и CPU) на одинаковой задаче. Учитывая скорость разработки и количество библиотек, выбор очевиден.
А сейчас расширение функционала (адаптеры к разным системам хранения, сервера, воркеры) именно так и делаются — все на Go
Only those users with full accounts are able to leave comments. Log in, please.
Опыт написания асинхронного поллинга сетевых устройств