На чём лучше писать большого демона?

Question

[Алексей Солодкий]

Задача написать большую сложную систему которая будет стабильно работать в фоновом режиме длительное время.

Сам я специализируюсь на PHP но понимаю что он под эту задачу не очень подходит.

Что посоветуете? Руби, питон, с фреймворком или чистый.

Хотелось бы иметь удобною работу с бд (ORM?), http.

Спасибо.

Answer 1

[giner]

Небольшая история.
— Первый свой демон писал на Питоне (это был питон 2.6 или 2.7, не помню уже). Работал но кушал много памяти, при чём со временем кушал всё больше. Разлюбил.

Затем начал писать на perl. Всё было хорошо, до тех пор пока демон должен был работать на Linux. Когда понадобилось перенести на Windows, обнаружились проблемы (форки рождались, но не убивались), которые так и не удалось решить. Возможно perl сильно полагается на архитектуру Linux.

Затем я решил попробовать ruby и обнаружил скриптовый рай. Демон, который прежде был написан на perl был легко перенесён на ruby, при чём код сократился раза в два. Под Windows не пришлось допиливать вообще ничего. Работает одинаково везде.
— В конце концов я для себя решил, что если писать скрипты-утилиты, то и perl и bash подойдёт, а если демоны, то ruby.
Производительность я не беру в учёт, т.к. никогда не требовалось, а вот по простоте и переносимости ruby на высоте.

Answer 2

[kasthack]

Настоящих демонов пишут на Аде.

Comments

[Марат]

)

[Mage From The Space]

)

Answer 3

[Zerstoren]

Автор, понимаю вас. Когда-то я имел неосторожность написать демона на PHP, о чем жалею. Хоть работал стабильно, но меня он харил.

Python — замечательный язык для такой задачи, те кто пишут про утечки памяти, не сильно помогали сборщику мусора.
Я пишу демонический вебсокет сервер, при тысяче входов и выходов, на протяжении нескольких дней, утечки не зафиксированы. Как код жрал 7мб оперативки, так после отключения всех юзеров и продолжал жрать 7мб оперативки. Отличия сводились на килобайты.

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

Ничего не оставляйте без присмотра.

Comments

[kamiram]

подтверждаю. утечки как правило изза долгоживущих сущностей

[alz]

Да это и не утечки в классическом смысле. Держите ссылки на объекты, которые вам больше не нужны? ССЗБ

Answer 4

[jetman]

Большая и сложная система? Прорекламирую ключевые особенности Golang применительно к вашему случаю:
— статическая типизация
— легковесные потоки «из коробки»
— обширная стандартная библиотека
— встроенная система юнит-тестирования
— прост в изучении для PHP программистов

golang.org

Comments

[Sergey Lerg]

Присоединяюсь, Go отлично подходит.

[Sergey Cherepanov]

Да сам как php программист тоже советую посмотреть на Go, но прийдется немного по другому научиться думать))

[Андрей Ширяев]

Только примеров автор не найдет. А уж о библиотеках которые упростят это дело и мечтать не стоит. Язык великолепен, мне довелось с ним поработать, но с поддерживаемыми библиотеками там проблема.

[jetman]

Автор топика только туманно упомянул об ORM и http клиенте. Работа с HTTP в Golang организована на отлично, database/sql предоставляет подключение к БД. Да, у database/sql есть недостатки и крутых ORM для Golang нету, но если придерживаться принципа KISS, то ORM вполне заменяется набором утилит вроде gosexy.org/db

Answer 5

[TyShkan]

Рекомендую посмотреть в сторону phpdaemon

Answer 6

[afiskon]

Думаю, вам подойдет Perl или Erlang. Perl очень легко учится после PHP, на нем без труда пишутся демоны, есть замечательный ORM (DBIx::Class). Erlang прекрасен неизменяемыми переменными, функциональным стилем, многопоточностью и автоматической сборкой мусора. Есть замечательный веб-сервер (не фреймворк) Cowboy. Правда, с ORM у него не все гладко, как и с дровами для СУБД (в emysql есть известные незакрытые баги, в epgsql — проблемы с производительностью, если запросов очень много). Обо многом из перечисленного я когда-то писал у себя в бложике, можете по нему поискать.

Answer 7

[kamiram]

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

Comments

[kamiram]

*php значительно более жруч :)

Answer 8

[lsf]

На твоем месте я бы остановился на PHP. Попутно разобрался бы с тем что такое crontab. Если этого тебе будет мало, будешь думать о чем то ещё.

Comments

[Алексей Солодкий]

Я знаю что такое crontab. В php меня расстраивает хотя-бы отсутствие многопоточоности и другие мелкие вещи.

[lsf]

Тогда возможно тебе подойдет Java.
А вообще то, если говорить про " сложную систему которая будет стабильно работать в фоновом режиме" это больше вопрос архитектуры этой системы чем языка.

[Алексей Солодкий]

>Это больше вопрос архитектуры этой системы чем языка.
Да. Конечно. Но влияние языка тоже есть.

[ajaxtelamonid]

непонятно, почему заминусовали коментарий. Супервайзер на кроне и/или самоперезапускающийся воркер(ы) — нормальное решение.

[rPman]

Это решение из разряда 'bad practices'.
Очень много времени приложение, запускаемое по крону, тратит на 'восстановление состояния', конечно бывают задачи, когда для этого достаточно обычной БД, или когда таких данных очень мало. Но самое главное, работа по крону — это задержка в реакции демона на события.

[ajaxtelamonid]

Так работать и реагировать будет воркер, который крутится в памяти. А на кроне будет висеть супервайзер, задача которого — запустить внезапно упавший воркер или прибить его, если тот память начал жрать.

Answer 9

[vsespb]

Perl отлично подойдёт.

Answer 10

[B7W]

Если вам надо серьезное большое многопоточное приложение — лучше смотреть в сторону java. Тамошняя библиотека, да и виртуальная машина, наиболее предпочтительней подходят под такие задачи.

Python, Ruby имеют GIL. И серьезных инструментов для многопоточности в них нет.
В python есть обход GIL — пакет multiprocessing, если смотреть то на него. ORM — SQLAlchemy, http — есть базовый и другие библиотеки.

А вообще надо смотреть задачи, а то может вам и php хватит.

Answer 11

[DrNemo]

в первую очередь все зависит от задач демона!
приведу пример: у меня есть демон собирающий много статистики с моих проектов и контролирующий их доступность. проекты на контроле разные, есть и средненагруженные.
так вот, демон написан на питоне и работает на моем старом десктопе на базе intl celeron 1,7 с 2 гигами оперативы(DIMM)
комп под управлением ubuntu server
железо вполне вытягивает решаемые демоном задачи.

Answer 12

[Ogoun Er]

C# отлично подойдет, делаю на нем невыгружаемые приложения, стабильно работают месяцами, память не протекает.

Answer 13

[sylord]

Один большой лучше не делать. А написать несколько, которые выполняют различные задачи. А тут уже решать на чем писать. Где то хватит и Bash, где то необходим (либо быстрее) тот же PHP. Если грамотно писать никуда ничего не течет. Еще обязательно на демон повесить что то типа monit.

Answer 14

[porzione]

Выше уже сказали про требования, поэтому важно знать
1. критично ли потребление памяти? надо ли уложиться в 50 мб, 100 мб, 200 мб?
2. нужно ли отвечать параллельно на несколько запросов и нужна ли реальная многопоточность?

Если на второй вопрос ответ «да», то Erlang, например.

Comments

[Алексей Солодкий]

1. Не критично.
2. реальная многопоточность не нужна.

[porzione]

Конечно Erlang это практически идеальная штука, но потребует времени на вхождение в язык и функциональную парадигму вообще. Но многопоточность там оч хороша. Из своего опыта могу посоветовать Ruby и что-нибудь из www.ruby-toolbox.com/categories/daemonizing и это еще не все — руби хорош огромным сообществом и соотв кучей примеров и ресурсов. Для работы с очередью задач есть github.com/collectiveidea/delayed_job, для работы с событиями github.com/eventmachine/eventmachine — это все решения которые активно используются в продакшене.

Answer 15

[plutov]

Я пишу на PHP, работает стабильно, но хочется перейти на Go plutov.by/post/php_daemons