Ну вы так быстро ответили "да", видимо не поняли вопроса. Я даже удивился :) Конфиг из статьи к jss не имеет никакого отношения.
То, что by design — это понятно, но помечтать о том, чтобы jss выдрать build-time, вполне можно, если не использовать его динамические фичи. Вот, например, попытка (насколько я понял, заброшенная) сделать что-то на эту тему: https://github.com/markdalgleish/jss-loader
Как это хозяйство работает с кешем файловой системы. Мы используем PostgreSQL, скорость его работы очень сильно зависит от того, какой объём активно используемых им файлов залезет в кеш файловой системы. На обычном железе кеш файловой системы откушивает практически всю свободную память. В вашей же системе память типа бесконечная (если не считать лимиты).
Нет, специальных исследований с стресс-тестов для PHP 5.3 я не проводил. Есть только опыт того, что даже в fastcgi иногда приходится всё перезапускать, чтобы оно вздохнуло. Правда больше у нас работал 5.2, но и с 5.3 в последнее время возникают инциденты.
Ну как косвенный аргумент можно привести наличие переменной PHP_FCGI_MAX_REQUESTS или настройки pm.max_requests? В эрланге ничего подобного нет.
Наверное, если бы я был снова студентом и у меня была куча времени на различные интересные исследования, я бы рискнул попробовать писать на PHP всё подряд. Но, видимо, я старею, и начинаю тянуться к надёжности :)
не верная гипотеза приводит к неверным результатам…
Если исходить из того, что гипотеза не верна, то, конечно же, во всём остальном я с вами соглашусь. Но заметьте, что вы первый, кто поставил её под сомнение. Такая у PHP репутация нехорошая, и, поверьте, она не на пустом месте.
Я не доверю интерпретатору PHP длинные задачи, не буду делать так, чтобы от стойкости php-процесса зависела надёжность всей системы. Не предназначен он для этого. Скорее всего, даже разработчики самого PHP вам скажут то же самое.
Но в принципе спасибо за ваше мнение, я его уважаю. Наверное, если хорошо потрудиться, то можно соорудить что-нибудь более-менее сносное и на чистом PHP. Но я верю, что проще это будет сделать на инструменте, который для подобных задач лучше подходит.
простите а это что vladimirbarbarosh.blogspot.com/2011/05/compile-php-536-pecl-libevent-004.html?
Это какой-то кул-хацкер на коленках что-то скомпилировал. От этого ни phpDaemon, ни php-fpm Windows поддерживать не начали. Но спасибо за наводку, libevent под винду есть — значит не всё потеряно :)
я не предлагаю делать диспетчер на PHP, я предлагаю использовать одно из лучших решений на рынке, написанный на Erlang — RabbitMQ
Аналог cron-а?
Он у нас уже есть, поскольку сам крон не умеет решать задачи типа «сделать что-то каждую вторую пятницу чётного месяца в 11:00», а нам это нужно.
На Erlang нужен только инициатор, который вовремя запустит PHP.
То, что Вы не умеете пользоваться CLI в PHP — не значит, что Ваши программы надо запускать исключительно по HTTP.
А что там, собственно, нужно «уметь»? Мы сейчас используем запуск задач по cron. Могу сказать, что это неудобно как минимум тем, что трудно контролировать количество таких задач, работающих в данный момент — довольно просто себя задосить.
Что касается производительности — я не проводил бенчмарков, а вы проводили? Откуда информация, что запуск через HTTP+FastCGI будет работать дольше, чем через прямой CLI вызов? Как мы все знаем, FastCGI для того и придумали, чтобы не разбазаривать ресурсы на постоянный fork при использовании CGI.
В принципе, java — единственный альтернативный кроссплатформенный вариант решения всех обозначенных задач.
Но java — это универсальный монстр, на котором вроде как даже операционную систему написали уже. А erlang — инструмент, который хорошо решает именно те задачи, которые нужно, и есть подозрение, что эти задачи он решает лучше, чем java.
Кроме того, вам не кажется каким-то странным сочетание java и php? Сразу напрашивается вопрос — если уже java стоит, на фига php? На java можно решать все задачи, которые решаются на php. А вот на erlang писать веб-приложения, конечно, можно, но это не самый прямой путь.
Вот и получается, что по охвату функциональности: erlang + php = java :))
Так речь не идёт о том, чтобы разработчики, которые пишут прикладной софт на PHP изучали для решения описанных задач Erlang. Речь о том, чтобы сделать документированный продукт, с помощью которого PHP-разработчики будут решать задачи, используя только PHP и соответствующее API.
Мы сейчас как раз используем nncron в качестве подпорки для Windows. Это неудобно.
Суть идеи в том, чтобы вместо того, чтобы для каждой задачи таскать своё решение, взять одно решение — Erlang — и сделать всё на нём.
Было бы совсем замечательно, если бы можно было всё сделать на самом PHP и не думать о других решениях, но, мне кажется, я достаточно подробно описал, почему PHP плох для целого ряда задач.
Ну вы так быстро ответили "да", видимо не поняли вопроса. Я даже удивился :) Конфиг из статьи к jss не имеет никакого отношения.
То, что by design — это понятно, но помечтать о том, чтобы jss выдрать build-time, вполне можно, если не использовать его динамические фичи. Вот, например, попытка (насколько я понял, заброшенная) сделать что-то на эту тему: https://github.com/markdalgleish/jss-loader
Как постгрес у вас будет работать?
Ну как косвенный аргумент можно привести наличие переменной PHP_FCGI_MAX_REQUESTS или настройки pm.max_requests? В эрланге ничего подобного нет.
Наверное, если бы я был снова студентом и у меня была куча времени на различные интересные исследования, я бы рискнул попробовать писать на PHP всё подряд. Но, видимо, я старею, и начинаю тянуться к надёжности :)
Если исходить из того, что гипотеза не верна, то, конечно же, во всём остальном я с вами соглашусь. Но заметьте, что вы первый, кто поставил её под сомнение. Такая у PHP репутация нехорошая, и, поверьте, она не на пустом месте.
Я не доверю интерпретатору PHP длинные задачи, не буду делать так, чтобы от стойкости php-процесса зависела надёжность всей системы. Не предназначен он для этого. Скорее всего, даже разработчики самого PHP вам скажут то же самое.
Но в принципе спасибо за ваше мнение, я его уважаю. Наверное, если хорошо потрудиться, то можно соорудить что-нибудь более-менее сносное и на чистом PHP. Но я верю, что проще это будет сделать на инструменте, который для подобных задач лучше подходит.
Это какой-то кул-хацкер на коленках что-то скомпилировал. От этого ни phpDaemon, ни php-fpm Windows поддерживать не начали. Но спасибо за наводку, libevent под винду есть — значит не всё потеряно :)
Тогда нужно завязывать лицензию на hardware-ключ, а такого решения для PHP нет.
я не предлагаю делать диспетчер на PHP, я предлагаю использовать одно из лучших решений на рынке, написанный на Erlang — RabbitMQ
Он у нас уже есть, поскольку сам крон не умеет решать задачи типа «сделать что-то каждую вторую пятницу чётного месяца в 11:00», а нам это нужно.
На Erlang нужен только инициатор, который вовремя запустит PHP.
А что там, собственно, нужно «уметь»? Мы сейчас используем запуск задач по cron. Могу сказать, что это неудобно как минимум тем, что трудно контролировать количество таких задач, работающих в данный момент — довольно просто себя задосить.
Что касается производительности — я не проводил бенчмарков, а вы проводили? Откуда информация, что запуск через HTTP+FastCGI будет работать дольше, чем через прямой CLI вызов? Как мы все знаем, FastCGI для того и придумали, чтобы не разбазаривать ресурсы на постоянный fork при использовании CGI.
Но java — это универсальный монстр, на котором вроде как даже операционную систему написали уже. А erlang — инструмент, который хорошо решает именно те задачи, которые нужно, и есть подозрение, что эти задачи он решает лучше, чем java.
Кроме того, вам не кажется каким-то странным сочетание java и php? Сразу напрашивается вопрос — если уже java стоит, на фига php? На java можно решать все задачи, которые решаются на php. А вот на erlang писать веб-приложения, конечно, можно, но это не самый прямой путь.
Вот и получается, что по охвату функциональности: erlang + php = java :))
А к перлу у меня личная неприязнь, сори :)
Суть идеи в том, чтобы вместо того, чтобы для каждой задачи таскать своё решение, взять одно решение — Erlang — и сделать всё на нём.
Было бы совсем замечательно, если бы можно было всё сделать на самом PHP и не думать о других решениях, но, мне кажется, я достаточно подробно описал, почему PHP плох для целого ряда задач.