У меня есть простенький демон на silex, работает месяцами, стучит курлом к внешнему ресурсу, собирает данные и обновляет некий срез. Стабильно работает месяцами, иногда я его перезапускаю «на всякий случай», но утечек за ним я не наблюдал. и там точно не php 7. Полагаю, что ваши утечки – это проблемы из вашего же кода/фреймворка. Просто Yii не выглядит чем-то не «рожденным чтобы умереть».
не понимаю о чем вы, всю жизнь ломал процессы компаний, навязывая свои условия, и никто меня так и не уволил.
и больше трех лет нигде также не работал, потому что и правда начинает съедать рутина, а это негативно сказывается на производительности. и кому было бы хорошо, если бы я остался?
Хотя изъяны этих кейсов также очевидны, как изъяны предложенных в статье, но я бы предложил следующий алгоритм:
1. Смержить не скрипты, но критерии оценки эффективности скриптов
2. Разделить бонус в случае, если результаты оценки эффективности будут приблизительно равны
3. Поручить командам поддерживать свои варианты скриптов
4. Постфактум дополнительно премировать команду, реализация которой оказалась более живучей
Автор привязывается в описании к потоку при этом очевидно не раскрывая контекст. Если принять за контекст ограничение количества потоков, то статья приобретает смысл.
Но опять же порождая массу уточнений. Каждый из потоков выполнит свою задачу (отработав ровно столько времени, сколько для этого потребуется) и освободится, и ни один из них не будет простаивать. При этом в определенных ситуациях у них все равно могут возникнуть взаимные блокировки из-за внешних ограничений (н-р пропускная способность шины). Так что говорить об абсолютной свободе или отсутствии потоков в асинхронном I/O не приходится.
А можете объяснить, что именно вы пытаетесь объяснить?
Потому что в вашем объяснении то и время встречаются различные потоки либо прерывания, которые так или иначе участвуют в операции ввода/вывода. Возможно какой-то отдельный поток не создается на уровне приложения, однако где-то на уровне ОС и драйверов какие-то потоки все же задействованы. И если назвать процесс записи внутри устройства потоком, то он-то как раз и жертвует собой, в то время, когда другие процессы/потоки не заняты этой операцией?)
и больше трех лет нигде также не работал, потому что и правда начинает съедать рутина, а это негативно сказывается на производительности. и кому было бы хорошо, если бы я остался?
Еще один баг, из оперативной памяти случайным образом пропадают связанные с обрабатываемой в данный момент информацией данные.
1. Смержить не скрипты, но критерии оценки эффективности скриптов
2. Разделить бонус в случае, если результаты оценки эффективности будут приблизительно равны
3. Поручить командам поддерживать свои варианты скриптов
4. Постфактум дополнительно премировать команду, реализация которой оказалась более живучей
Автор привязывается в описании к потоку при этом очевидно не раскрывая контекст. Если принять за контекст ограничение количества потоков, то статья приобретает смысл.
Но опять же порождая массу уточнений. Каждый из потоков выполнит свою задачу (отработав ровно столько времени, сколько для этого потребуется) и освободится, и ни один из них не будет простаивать. При этом в определенных ситуациях у них все равно могут возникнуть взаимные блокировки из-за внешних ограничений (н-р пропускная способность шины). Так что говорить об абсолютной свободе или отсутствии потоков в асинхронном I/O не приходится.
Потому что в вашем объяснении то и время встречаются различные потоки либо прерывания, которые так или иначе участвуют в операции ввода/вывода. Возможно какой-то отдельный поток не создается на уровне приложения, однако где-то на уровне ОС и драйверов какие-то потоки все же задействованы. И если назвать процесс записи внутри устройства потоком, то он-то как раз и жертвует собой, в то время, когда другие процессы/потоки не заняты этой операцией?)
Причем события, которые нужно выполнить «сейчас», вполне ложатся под идею планировщика. А вот отложенные события в идею очередей – никак.
Рассуждая дальше приходим к выводу, что это не система очередей, а планировщик, использующий проприетарную самописанную систему очередей.
Что вобщем-то довольно полезно.
Хотя сервер очередей можно было бы вынести во внешний протокол и разрешить использование сторонних MQ-серверов через протокол AMQP например.