Comments 117
Отлично, спасибо! как раз столкнулся с задачей, где это очень нужно!
Автор, планируете про общий доступ у ресурсам написать второй статьей?
В чём преимущество писать демоны на PHP?
Вы пишете: «Задачи: Выполнение трудоемких фоновых задач», здесь как раз и нужно использовать С/С++.
Я PHP конечно люблю, но так бы извращаться не стал. :)
P.S. За старания +.
Вы пишете: «Задачи: Выполнение трудоемких фоновых задач», здесь как раз и нужно использовать С/С++.
Я PHP конечно люблю, но так бы извращаться не стал. :)
P.S. За старания +.
Речь идет о демонах в составе сайта, то есть, вторичных по отношению к сайту, то есть, таких, в которых удобно использовать фреймворк, использованный на самом сайте.
Вот и преимущество.
Вот и преимущество.
ммм, систему мгновенного обмена сообщениями можно состряпать, а уж сколько всякого интересного с кешированием можно напридумывать, удобно.
Жаль… очень жаль, что хостеры ещё не скоро это разрешат.
Жаль… очень жаль, что хостеры ещё не скоро это разрешат.
VPS'ы покупайте, стоят не дорога и делайте что хотите.
Да это ясен пень, но дороже чем обычный хостинг несколько.
Хотя вообще, если проекту требуются такие демоны… то на обычном хостинге глупо его хостить.
Хотя вообще, если проекту требуются такие демоны… то на обычном хостинге глупо его хостить.
имхо любой мало-мальски серьезный проект требует VPS
вот мой домашний проектик полностью грузит 4х ядерную систему с 6-ю гигами памяти 8-)
вот мой домашний проектик полностью грузит 4х ядерную систему с 6-ю гигами памяти 8-)
Фреймворк, висящий в памяти в виде демона не слишком ли много отожрёт?
а сколько он отожрёт?
А при чем здесь фреймворк? В памяти будет висеть один скрипт-демон
Речь идет о демонах в составе сайта, то есть, вторичных по отношению к сайту, то есть, таких, в которых удобно использовать фреймворк, использованный на самом сайте.
Я вот об этом. Там внизу про это тоже пишут.
Во-первых, в 5.3 появился достойный сборщик мусора.
Во-вторых, это зависит от того, как писался демон. Отжирать память может любой скрипт на любом языке.
Во-вторых, это зависит от того, как писался демон. Отжирать память может любой скрипт на любом языке.
Отличная статья.
Пока что этого:
$pid = pcntl_fork();
if ($pid == -1) {
//ошибка
} elseif ($pid) {
//сюда попадет родительский процесс
} else {
//а сюда — дочерний процесс
}
//а сюда попадут оба процесса
для моих целей вполне хватало, но автор все очень толково расписал.
Кстати, хочу предупредить: если в программе есть ресурсы соединения с БД, то перед ветвлением их лучше закрыть, и в дочерних процессах открывать свои, которые должны завершаться в конце жизни процессов.
Пока что этого:
$pid = pcntl_fork();
if ($pid == -1) {
//ошибка
} elseif ($pid) {
//сюда попадет родительский процесс
} else {
//а сюда — дочерний процесс
}
//а сюда попадут оба процесса
для моих целей вполне хватало, но автор все очень толково расписал.
Кстати, хочу предупредить: если в программе есть ресурсы соединения с БД, то перед ветвлением их лучше закрыть, и в дочерних процессах открывать свои, которые должны завершаться в конце жизни процессов.
Вот, наконец-то… А то задрали снизу с «многопоточностью» )))
То, о чем и говорили — демонизация и раздача заданий рулит ;)
То, о чем и говорили — демонизация и раздача заданий рулит ;)
UFO just landed and posted this here
Кстати, если нужно хапустить такой «демон» по какому-либо событию с сайта (например, по нажатию кнопки), чтобы он не завершился при закрытии странины в браузере, можно сделать так:
pclose(popen($exec,'r'));
где в $exec будет строка типа «php-cgi /path/to/php/script.php»
pclose(popen($exec,'r'));
где в $exec будет строка типа «php-cgi /path/to/php/script.php»
Спасибо! Жду еще статей ;)
Однозначно в избранное! Все толково разжованно. Что то поднобное делал для мыльной рассылки, но без многопоточности.
Вы выросли из PHP. Вам пора переходить на Python/Ruby.
что руби и питон сложнее?:)
напротив :) Впрочем, вы просто попробуйте, и сами меня прекрасно поймёте. Через месяц PHP будет казаться экспонатом кунсткамеры.
по-моему вы не заметили мой сарказм:) просто почемуто в вашем комментарии создается впечатление что пхп это некий начальный простой этап, не вижу смысла его проходить если можно начать сразу с питона, при этом даже никогда не заниматся веб-разработкой
вечером с юмором туго :) Я не хотел показать PHP начальным этапом. Жаль, если так вышло. Учебно-воспитательный эффект от него сильно негативный. Но, увы, у многих он стал первым. И больно смотреть, как через несколько лет, уже взрослые люди пытаются этой корягой решить задачи, для которых она совершенно не годится. Нет, решить-то конечно можно, но… это всё равно что строить из ДСП плотины ГЭС или танки из пенопласта.
Главное чтобы руки росли из грамотных мест, а на чем писать вопрос уже вторичный Одну и ту же бизнес логику можно описать на любом из серверных языков, цена вопроса +- 10 строк. Что такого можно написать на ruby или python чего нельзя написать на php… Я так понимаю php не может быть крутым, только потому что на нем пишет ну очень много народа!
Про руки — согласен. Но, почему-то, все толковые PHP-программисты, которых я встречал, изначально писали на С++/Java/Pascal и близких языках, делая на них большие проекты. И напротив, среди тех, кто два-три года писал только на PHP и ничего другого в жизни не видел, я ещё не видел ни одного грамотного разработчика, способного правильно поставить и красиво решить проблему.
Массовость языка PHP тут не при чём. Если уж на то пошло, C++ и Java — куда более массовые языки. Windows тоже массовый, и хотя он страшно крив, маркетинг своё дело сделал. С PHP случилось то же самое. Года четыре тому назад все СМИ как заведённые писали про «удивительно простой и замечательный язык». Модно было.
Про его разработку стоит сказать особо. Когда кому-то нужна была функция «выбрать из массива каждый второй элемент и просуммировать их» — она сразу добавлялась в ядро! Потом следовала функция «выбрать каждый третий элемент и перемножить», и так до бесконечности… Я до сих пор помню, как один из создателей PHP так и охарактеризовал процесс разработки: «Более-менее управляемый хаос». PHP- это язык без «стержня», без структуры, без проектирования, без целей и… без будущего. Я сам писал на PHP около 2 лет, поэтому могу быть объективным.
Но, как и всё массовое, сразу он со сцены не уйдёт. Слишком большие деньги вбуханы в проекты на нём. Слишком много разработчиков им кормится. Это его и похоронит. Потому что весь этот балласт не даст переродить язык. Здесь нет Линуса Торвальдса, который скажет «мы полностью переделываем работу с оборудованием, и баста!». Нет своей Sun, которая тщательно следила за архитектурой Java. Нет Страуструпа (C++). А есть только очень-очень-очень-очень много малоквалифицированных кодеров, и 2-3% серьёзных разработчиков, которым действительно всё равно на чём писать. Но как раз последние и не станут делать танки из пенопласта — они способны использовать лучшие инструменты.
Я так понимаю php не может быть крутым, только потому что на нем пишет ну очень много народа!
Массовость языка PHP тут не при чём. Если уж на то пошло, C++ и Java — куда более массовые языки. Windows тоже массовый, и хотя он страшно крив, маркетинг своё дело сделал. С PHP случилось то же самое. Года четыре тому назад все СМИ как заведённые писали про «удивительно простой и замечательный язык». Модно было.
Про его разработку стоит сказать особо. Когда кому-то нужна была функция «выбрать из массива каждый второй элемент и просуммировать их» — она сразу добавлялась в ядро! Потом следовала функция «выбрать каждый третий элемент и перемножить», и так до бесконечности… Я до сих пор помню, как один из создателей PHP так и охарактеризовал процесс разработки: «Более-менее управляемый хаос». PHP- это язык без «стержня», без структуры, без проектирования, без целей и… без будущего. Я сам писал на PHP около 2 лет, поэтому могу быть объективным.
Но, как и всё массовое, сразу он со сцены не уйдёт. Слишком большие деньги вбуханы в проекты на нём. Слишком много разработчиков им кормится. Это его и похоронит. Потому что весь этот балласт не даст переродить язык. Здесь нет Линуса Торвальдса, который скажет «мы полностью переделываем работу с оборудованием, и баста!». Нет своей Sun, которая тщательно следила за архитектурой Java. Нет Страуструпа (C++). А есть только очень-очень-очень-очень много малоквалифицированных кодеров, и 2-3% серьёзных разработчиков, которым действительно всё равно на чём писать. Но как раз последние и не станут делать танки из пенопласта — они способны использовать лучшие инструменты.
PHP- это язык … без будущего. Я сам писал на PHP около 2 лет, поэтому могу быть объективным.Очень сомневаюсь в Вашей объективности относительно будущего PHP, да и 2 года весьма короткий срок для таких утверждений. На мой взгляд, с PHP все будет хорошо.
Сомневайтесь, ваше право. Давайте только не переходить на личности. До PHP мне довелось много на чём писать, поэтому, когда я столкнулся с PHP, у меня уже было с чем сравнивать. И сравнение было не в пользу последнего.
А насчёт будущего — оно всех и рассудит. Лично я уверен, что доля PHP будет медленно, но неуклонно снижаться, если с языком не случится коренных перемен, которые перечеркнут всё его тёмное прошлое. Что мы сейчас и наблюдаем с Perl. И я описал, почему лично я сомневаюсь в возможности таких крутых перемен.
А насчёт будущего — оно всех и рассудит. Лично я уверен, что доля PHP будет медленно, но неуклонно снижаться, если с языком не случится коренных перемен, которые перечеркнут всё его тёмное прошлое. Что мы сейчас и наблюдаем с Perl. И я описал, почему лично я сомневаюсь в возможности таких крутых перемен.
Ну, пхп, все ещё довольно простой и поэтому самый распространенный. В ближайшее время с ним ничего страшного не произойдет.
Тем не менее, все больше людей обращают внимания на преимущества других языков, таких как руби или питон, которые в свою очередь поддерживаются хостерами сейчас уже гораздо лучше чем даже в прошлом году.
Лично я предпочитаю не говорить о недостатках пхп, а стараюсь рассказывать достоинствах и отличиях того с чем работаю сам. Люди со временем сами будут делать выбор.
Тем не менее, все больше людей обращают внимания на преимущества других языков, таких как руби или питон, которые в свою очередь поддерживаются хостерами сейчас уже гораздо лучше чем даже в прошлом году.
Лично я предпочитаю не говорить о недостатках пхп, а стараюсь рассказывать достоинствах и отличиях того с чем работаю сам. Люди со временем сами будут делать выбор.
недавно ходил на собеседование, как раз спрашивали о переходе на руби. т.к. на работу мне как-то параллельно, не стал подлизываться и сказал, что после близкого знакомства с руби мне как-то расхотелось. почему? я могу сделать на пыхе всё тоже что и на руби и немножко больше. тех. деректор думал как и я.
этап когда руби было модно уже прошёл. это видно даже по зарплатам.
ну а для нетепичных для вэб языка задач, действительно, иногда лучше использовать Python, потому как php ещё не готов. но руби никуда не годится.
P.S. Минусуя аргументируйте, задрала мне гигемония ubunta/firefox/mac/ruby
этап когда руби было модно уже прошёл. это видно даже по зарплатам.
ну а для нетепичных для вэб языка задач, действительно, иногда лучше использовать Python, потому как php ещё не готов. но руби никуда не годится.
P.S. Минусуя аргументируйте, задрала мне гигемония ubunta/firefox/mac/ruby
А почему минусующие должны аргументировать, а вы — нет? Если прямо сейчас вы PHP знаете лучше, разве это повод ругать то, в чём не разбираетесь? Я вот знаю русский язык лучше всего, но не заявляю, что английский — паршив, только потому, что не могу на нём также красиво выражаться.
кажется, не я начал эту ветку. а лишь спорил с необосновонность начального утверждения.
моя аргументация в посте выше — познакомившись с руби поближе, я сделал выводы, что на php могу сделать тоже самое. какой тогда смысл менять язык со всеми наработками.
помню, меня хотели впечатлить роликом с быстрой разработкой фотогаллереии, но используя свои наработки я и так делаю такую же меньше чем за 5 минут.
вот в освоении пайтон я вижу смысл, так как он не только вэб язык и может дополнить php.
моя аргументация в посте выше — познакомившись с руби поближе, я сделал выводы, что на php могу сделать тоже самое. какой тогда смысл менять язык со всеми наработками.
помню, меня хотели впечатлить роликом с быстрой разработкой фотогаллереии, но используя свои наработки я и так делаю такую же меньше чем за 5 минут.
вот в освоении пайтон я вижу смысл, так как он не только вэб язык и может дополнить php.
«come to the dark side, we have cookies?» :)
Честно говоря, если учесть, что я уже перешел на haml и sass, до руби недалеко.
Пока что испытываю панический страх, что все, освоенное мной в плане ПХП, станет ненужным.
Честно говоря, если учесть, что я уже перешел на haml и sass, до руби недалеко.
Пока что испытываю панический страх, что все, освоенное мной в плане ПХП, станет ненужным.
UFO just landed and posted this here
Не бойтесь, на тёмной стороне нет ничего страшного, всё очень даже здорово! :)
Я, например, безнадёжно влюблён в Django :) Два года его применяю, и всё это время не перестаю им восторгаться. За всю мою программистскую практику такого удовольствия в работе я не получал ни от одного инструмента. Очень рекомендую!
Я, например, безнадёжно влюблён в Django :) Два года его применяю, и всё это время не перестаю им восторгаться. За всю мою программистскую практику такого удовольствия в работе я не получал ни от одного инструмента. Очень рекомендую!
UFO just landed and posted this here
Похожее описывается в книге Дж. Шлосснейгла «Профессиональное программирование на PHP. (Adv. Php programming)». Там есть еще пару дополнительных примеров, касательно форкинга и создания демонов. Если интересно, то позже выложу код в блоге.
выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
Ну это легко можно поправить с помощью ini_set() или в php.ini
А вообще статья познавательная, хотя конечно, имхо, лучше такие штуки на сях писать =)
шикарно!
респект и уважуха.
респект и уважуха.
Как у вас в PHP всё сложно с демонами-то=)
Не то, что в Perl, который в том числе и для этого существует=)
Не то, что в Perl, который в том числе и для этого существует=)
Жаль, что перл не существует для создания веб-приложений. А то цены б ему не было :)
Не понимаю — в чём сложность написать веб-приложение на Perl?=)
Примеров реализации — пруд пруди-)
Примеров реализации — пруд пруди-)
Ну и тем более, кстати говоря — все, нужные по работе веб приложения, я пишу именно на Perl — чтобы не смешивать, так сказать=) Порой получается быстрее — да и расслабляться не приходится — интересней)
Простите, что я еще не пытался искать сам, просто раз уж подвернулся случай — грех не спросить.
Как можно из PHP посылать сигналы сторонним процессам? Желательно без использований расширений, но возможно с запуском системных утилит.
Как можно из PHP посылать сигналы сторонним процессам? Желательно без использований расширений, но возможно с запуском системных утилит.
Восьмидесяти этажные торговые центры с подземными парковками… из картонных коробок.
Знаю-знаю, не нравиться не нем… :)) сорре
Знаю-знаю, не нравиться не нем… :)) сорре
В принципе, можно также «распараллелить» процесс, используя popen('php') с соответствующими параметрами, а потом обмениваться с ним информацией через сокеты.
UFO just landed and posted this here
Опечатка: «pcntl_fork возвращает дочернему процессу и PID дочернего процесса — родительскому». Так что же pcntl_fork возвращает дочернему процессу? (-:
Недочет:
В вашем варианте работы с pid_file'ом всё-ещё возможен одновременный запуск двух демонов. Чтобы этого избежать демон должен лочить пид-файл на запись в начале работы. Если это не удалось, то факт наличия существующего процесса можно даже не проверять — он точно есть, раз файл занят.
Дополнения:
При использовании веб-ориентированных фреймворков для создания любых долгоживущих процессов вообще и форкающихся демонов в частности надо с особой осторожностью следить за ресурсами, т.к. многие фреймворки имеют серьёзные проблемы с их утечкой, так как не рассчитаны на длительную работу и в таких условиях никем не тестировались. Проблема эта в основном происходит от довольно примитивного сборщика мусора в PHP, который ведётся на банальные циклические ссылки.
Так, например, во фреймворке symfony экземпляры sfAggregateLogger никогда не удаляются из-за циклической ссылки (где-то через sfEventManager) — как результат получается утечка памяти. И файловых дескрипторов, если используются sfFileLogger'ы.
Таких примеров очень много.
Пути решения — либо исправлять фреймворк, либо ограничивать время жизни рабочего процесса, как это сделано в apache.
Ещё: полезно иметь управляющие скрипты, поддерживающие как минимум общепринятые юниксовые команды start и stop. Такие скрипты можно класть в rc.init (или rc.d) и таким образом обеспечить себе корректный подъём демонов при старте сервера и не менее корректное их завершение при выключении.
И ещё: не менее полезно перед началом любой работы переключаться в конкретную, определенную в конфигах рабочую директорию, дабы не плодить по файловой системе случайный/дебаговый вывод и не зависеть от того где в действительности был запущен демон.
Недочет:
В вашем варианте работы с pid_file'ом всё-ещё возможен одновременный запуск двух демонов. Чтобы этого избежать демон должен лочить пид-файл на запись в начале работы. Если это не удалось, то факт наличия существующего процесса можно даже не проверять — он точно есть, раз файл занят.
Дополнения:
При использовании веб-ориентированных фреймворков для создания любых долгоживущих процессов вообще и форкающихся демонов в частности надо с особой осторожностью следить за ресурсами, т.к. многие фреймворки имеют серьёзные проблемы с их утечкой, так как не рассчитаны на длительную работу и в таких условиях никем не тестировались. Проблема эта в основном происходит от довольно примитивного сборщика мусора в PHP, который ведётся на банальные циклические ссылки.
Так, например, во фреймворке symfony экземпляры sfAggregateLogger никогда не удаляются из-за циклической ссылки (где-то через sfEventManager) — как результат получается утечка памяти. И файловых дескрипторов, если используются sfFileLogger'ы.
Таких примеров очень много.
Пути решения — либо исправлять фреймворк, либо ограничивать время жизни рабочего процесса, как это сделано в apache.
Ещё: полезно иметь управляющие скрипты, поддерживающие как минимум общепринятые юниксовые команды start и stop. Такие скрипты можно класть в rc.init (или rc.d) и таким образом обеспечить себе корректный подъём демонов при старте сервера и не менее корректное их завершение при выключении.
И ещё: не менее полезно перед началом любой работы переключаться в конкретную, определенную в конфигах рабочую директорию, дабы не плодить по файловой системе случайный/дебаговый вывод и не зависеть от того где в действительности был запущен демон.
Абсолютно не залуживающая внимания тема. Во всех смыслах — исключительно академический интерес и наоборот, сосредоточение засилия быдлокодинга.
Такими темпами скоро на перл начнут модули ядра пробовать писать через прослойки и на дотнете драйвера для виндовс.
Если нужен многопоточный демон с автоподчисткой мусора — брать надо джаву. На худой конец питон. Но никак ни php. Еще немного, и критическая масса быдлокодеров начнет на нем пробовать писать игры=) Дайте же ему спокойно умереть, как устаревшему=)
Такими темпами скоро на перл начнут модули ядра пробовать писать через прослойки и на дотнете драйвера для виндовс.
Если нужен многопоточный демон с автоподчисткой мусора — брать надо джаву. На худой конец питон. Но никак ни php. Еще немного, и критическая масса быдлокодеров начнет на нем пробовать писать игры=) Дайте же ему спокойно умереть, как устаревшему=)
UFO just landed and posted this here
Уважаемый, я вас огорчу: на любом языке можно реализовать любой функционал (исключая клиентские вещи). Даже ось можно написать на PHP. Не суть важно ;)
Другое дело — смешивание 2-х и более языков в приложении. Кому оно нужно? Любой PHP-разработчик встречает задачи, который в нативном PHP не предусмотрены. И решает эти задачи.
Любой разработчик встречает задачи, которые в его нативном языке не предусмотрены. А демон на Java — это не меньший изврат, кстати ;)
ЗЫ: есть куча примеров Online-игр написанных на PHP. Все быдлокодеры?: D: D: D
Другое дело — смешивание 2-х и более языков в приложении. Кому оно нужно? Любой PHP-разработчик встречает задачи, который в нативном PHP не предусмотрены. И решает эти задачи.
Любой разработчик встречает задачи, которые в его нативном языке не предусмотрены. А демон на Java — это не меньший изврат, кстати ;)
ЗЫ: есть куча примеров Online-игр написанных на PHP. Все быдлокодеры?: D: D: D
UFO just landed and posted this here
Я от таких яванебыдлокодеров даже статейку видел: www.codenet.ru/webmast/java/javavscpp.php
Пля, отправил рано. ((
Суть в том, что НИ ОДИН ЧЕЛОВЕК из обсуждавших сию новость ни на коднете ни на лоре не согласился с результатами.
Так что не будем разводить холливар. А то достало уже показывать «небыдлокодерам» почему PHP не только отстоял свое право на жизнь у ASP.NET и JAVA в сфере Web, но и развивается нехило )))
Суть в том, что НИ ОДИН ЧЕЛОВЕК из обсуждавших сию новость ни на коднете ни на лоре не согласился с результатами.
Так что не будем разводить холливар. А то достало уже показывать «небыдлокодерам» почему PHP не только отстоял свое право на жизнь у ASP.NET и JAVA в сфере Web, но и развивается нехило )))
Будет более смешно, если на .net под Виндой начнут писать модули ядра под *nix.
Торвальдса хватит удар по дых…
Торвальдса хватит удар по дых…
просто «до кучи»
www.chabotc.com/phpsocketdaemon/
$daemon = new socketDaemon();
$server = $daemon->create_server('httpdServer', 'httpdServerClient', 0, 2001);
$daemon->process();
Performance:
Using apache bench (ab) on my home computer, using 256 concurrent, keep-alive requests over 50000 requests this server was able to serve over 4500(!) pages a second, and each page with a max latency of 0.15 ms. Yes i told you it was FAST didn't I?
www.chabotc.com/phpsocketdaemon/
$daemon = new socketDaemon();
$server = $daemon->create_server('httpdServer', 'httpdServerClient', 0, 2001);
$daemon->process();
Performance:
Using apache bench (ab) on my home computer, using 256 concurrent, keep-alive requests over 50000 requests this server was able to serve over 4500(!) pages a second, and each page with a max latency of 0.15 ms. Yes i told you it was FAST didn't I?
Рассказать как мы это делали на принципе псевдо демонов, где управление через БД, а разделяемые ресурсы через мемкеш и БД?
Хотя, бывали задачи когда нужно что-то написать в виде функции на си, но это уж редкость скорее.
Хотя, бывали задачи когда нужно что-то написать в виде функции на си, но это уж редкость скорее.
Хм… Ребята, давайте на PHP напишем PHP-машину, которая будет обрабатывать в реальном времени PHP, делать из него байткод и компилить в PHP. Ну заодно так же на PHP для PHP напишем компилятор PHP++. А почему бы и нет?
Все это к тому, что возможность написать что-то другое на PHP — это хорошо, но бездумно тратить ресурсы сервера такими задачами — нечто невообразимое.
Да, кстати — хоть кто-то делал бенчмаркинг такого решения по сравнению с форком на C/C++? Очень интересно будет посмотреть.
Статья хороша сама по себе как вводный курс в демонописание.
Но не на профильном языке для Web'а.
А то как-то совсем грустно — костыль на костыле для костыля с костылем…
Все это к тому, что возможность написать что-то другое на PHP — это хорошо, но бездумно тратить ресурсы сервера такими задачами — нечто невообразимое.
Да, кстати — хоть кто-то делал бенчмаркинг такого решения по сравнению с форком на C/C++? Очень интересно будет посмотреть.
Статья хороша сама по себе как вводный курс в демонописание.
Но не на профильном языке для Web'а.
А то как-то совсем грустно — костыль на костыле для костыля с костылем…
Я вот хотел вас удивить, что есть http-сервер, написанный на PHP, но у меня почему-то не открывается его сайт. :(
Насчет бенчмарка — а pcntl_fork это практически и есть никсовый fork(). Ну да, придется отфоркать весь интерпретатор, логично, но ведь интерпретатор — это программа на C, так что, по-моему, проигрыш в производительности компенсируется использованием привычного и удобного языка.
Самый ценный ресурс — время разработчика, не так ли?
Насчет бенчмарка — а pcntl_fork это практически и есть никсовый fork(). Ну да, придется отфоркать весь интерпретатор, логично, но ведь интерпретатор — это программа на C, так что, по-моему, проигрыш в производительности компенсируется использованием привычного и удобного языка.
Самый ценный ресурс — время разработчика, не так ли?
Я вот хотел вас удивить, что есть http-сервер, написанный на PHP, но у меня почему-то не открывается его сайт. :(
Насчет бенчмарка — а pcntl_fork это практически и есть никсовый fork(). Ну да, придется отфоркать весь интерпретатор, логично, но ведь интерпретатор — это программа на C, так что, по-моему, проигрыш в производительности компенсируется использованием привычного и удобного языка.
Самый ценный ресурс — время разработчика, не так ли?
Насчет бенчмарка — а pcntl_fork это практически и есть никсовый fork(). Ну да, придется отфоркать весь интерпретатор, логично, но ведь интерпретатор — это программа на C, так что, по-моему, проигрыш в производительности компенсируется использованием привычного и удобного языка.
Самый ценный ресурс — время разработчика, не так ли?
Самый ценный ресурс — это знания и умения правильно применить полученные знания. Вы немного не с той стороны к процессу разработки подходите.
Сделать быстро — не значит сделать хорошо.
В то же самое время «Сделать хорошо на С» неравно «Сделать хорошо на PHP»
Если бы было так, то PHP уже давно бы писали на PHP, последовав иным примерам.
Сделать быстро — не значит сделать хорошо.
В то же самое время «Сделать хорошо на С» неравно «Сделать хорошо на PHP»
Если бы было так, то PHP уже давно бы писали на PHP, последовав иным примерам.
UFO just landed and posted this here
Нет, пишу на том же PHP. И считаю PHP узкопрофильным специализированным решением, которое отлично работает в свое области, но использовать его ВЕЗДЕ — разгильдяйство и излишество.
UFO just landed and posted this here
nice -n 20 забыли
UFO just landed and posted this here
Ошибочка. Максимальный n при ренайсе «19». «20» задано как следующее значение просто для красоты и простоты. Как-бы говорит «Дальше уже некуда» ^_^. Т.е. разницы при ренайсе -n 20 и -n 100 никакой.
Вы его просто редко используете или не используете вообще.
Но это частность примера.
А в общем, ИМХО, решение на PHP таких задач некорректно и ресурсоемко. Сам уже наступал на такие грабли.
Вы его просто редко используете или не используете вообще.
Но это частность примера.
А в общем, ИМХО, решение на PHP таких задач некорректно и ресурсоемко. Сам уже наступал на такие грабли.
UFO just landed and posted this here
что-то я не пойму, как нохап — отдельная утилита — может быть проще чем чистый форк сразу после запуска скрипта.
UFO just landed and posted this here
Таки использую на практике fork в пхп, могу сказать, что в условиях Continuous Integration оно гораздо удобнее, unix-way. По поводу того, течет или нет — это уж как напишете.
А вот с легкостью замасштабировать демон с 1 процесса до 10 заменой одной строчки кода + рестартить это всё деплой скриптом, написанным в те же две строчки — это весьма удобно.
Приходилось пользоваться как первым вариантом, так и вторым, с CI — форк удобнее однозначно.
По поводу экстеншенов — если сидите и пишете большой проект со своей инфраструктурой — это не проблема.
А вот с легкостью замасштабировать демон с 1 процесса до 10 заменой одной строчки кода + рестартить это всё деплой скриптом, написанным в те же две строчки — это весьма удобно.
Приходилось пользоваться как первым вариантом, так и вторым, с CI — форк удобнее однозначно.
По поводу экстеншенов — если сидите и пишете большой проект со своей инфраструктурой — это не проблема.
какой класс?
а пару лет назад надо мою в ru_php смеялись когда я задвигал подобное. )
Вместо
sleep() используй usleep(). Так оно кошернее.
В своем время использовал popen ( string $command, string $mode ) для запуска нескольких демонов.
Перед этим должно пытался провертеть с помощью set_time_limit(0), т.к. хостинг позволял. Но долго бился головой, не знал почему скрипт убивается. Оказалось у апача есть еще свой тайм-аут. Соотв. скрипт, запущенный через апач убивается. Решил проблему так, что запускал через браузер скрипт, который запуск другие через popen мимо апача. Вроде работало.
Перед этим должно пытался провертеть с помощью set_time_limit(0), т.к. хостинг позволял. Но долго бился головой, не знал почему скрипт убивается. Оказалось у апача есть еще свой тайм-аут. Соотв. скрипт, запущенный через апач убивается. Решил проблему так, что запускал через браузер скрипт, который запуск другие через popen мимо апача. Вроде работало.
Несовсем понял про блокировку c pid-файлом. С каких делов процесс несможет удалить файл — вы же его нигде неблокируете. У вас про блокировку нислова. Или у меня где то дырка в фундаментальных знаниях. Статья супер спасибо.
Это на всякий случай. А вообще такая ситуация будет, если запустить два демона из-под двух разных пользователей.
Вы меня не поняли. Процесс аварийно завершился. А пид остался. Второй демон его удаляет и все хорошо. Но а если процесс не завершался а работает дальше при этом пид файл живет себе нормально, но он доступен на запись с другого потока, поскольку вы его не лочите. Второй демон спокойно удаляет этот пид и запускается.
Спасибо Вам наиогромнейшее!!!
Прочел Вашу статью, понял все с полпинка и написал демона, которого так не хватало нашему корпоративному серверу )) Все что нужно, чтобы понять, как же создаются демоны, и не только на PHP — в этой статье есть! А так как она про PHP — вообще роскошный подарок судьбы для меня ))
Причем написал я со всеми вытекающими типа start|stop|status|help, ну и все что у Вас в статье (за исключением, правда, многопроцессорности и многопоточности самого демона, это уже лишнее для меня в данном случае)
P.S.: где бы надыбать такую же хорошую статью по Drupal'у, чтобы самую-самую суть раскрывала, азы и принципы работа ядра и взаимодействия всего внутри самого двига, а то весь его дзен мне как-то недоступен пока )))
Прочел Вашу статью, понял все с полпинка и написал демона, которого так не хватало нашему корпоративному серверу )) Все что нужно, чтобы понять, как же создаются демоны, и не только на PHP — в этой статье есть! А так как она про PHP — вообще роскошный подарок судьбы для меня ))
Причем написал я со всеми вытекающими типа start|stop|status|help, ну и все что у Вас в статье (за исключением, правда, многопроцессорности и многопоточности самого демона, это уже лишнее для меня в данном случае)
P.S.: где бы надыбать такую же хорошую статью по Drupal'у, чтобы самую-самую суть раскрывала, азы и принципы работа ядра и взаимодействия всего внутри самого двига, а то весь его дзен мне как-то недоступен пока )))
Sign up to leave a comment.
Многопроцессовые демоны на PHP