Подскажите пожалуйста, если кто-то знает.. Возможно ли заставить php работать как "нормальный" fastcgi? Т.е., чтобы все запросы обрабатывал один и тот же скрипт, как, например, в perl.
Нужно, что бы php скрипт принимал fastcgi соединение? Это нужна PHP-шная библиотека - не встречал такой, pear тоже молчит. Так что вариант самому написать остается
По моему, никто из присутствующих не знает, как FastCGI должен работать на самом деле. Программисты, ептыть. lazy, нет, этого сделать нельзя, к сожалению. Вообще, к php есть патчик в виде php-fpm - fastcgi process manager, но он не дает управлять процессом, и сам форкает и киляет fcgi. Но поковыряв его исходники, думаю, можно добится нужного результата.
Написать на php FastCGI сервер можно. Но не нужно. Я думаю, для тебя не секрет, что это только PHP отличился с реализацией FastCGI, которая реализует лишь интерфейс обращения, но не принцип работы?
Думаю для тебя не секрет, что в перле вообще нет встроенного fastcgi, а есть перловые библиотеки, которые реализуют интерфейс? И я не понимаю твои "принципы работы". Все реализуется, просто PHP-fastcgi (типа fpm) работает на одном уровне, а написанный на PHP - другой. Для CGI скриптов тоже есть такие уровни... spawn-cgi например, реализует один уровень, CGI::Fast - другой. Просто они не встроены изначально в интерпретаторы, а в PHP благодоря тому, что он изначально разрабатывался как, одновременно, и модуль апача и cgi - встроить такое оказалось легко. Зависит от задач. Если задача - исполнять множество скриптов не рождая интерпретатор - удобен один уровень. Если задача написать свою математику в одном скрипте и принимать/выдавать данные по FastCGI - то удобна реализация на уровне скрипта. Для PHP я таких реализаций не нашел, но не очень и искал. Но, в принципе, написать самому не сложно.
Не читайте гадости "Принципы работы" описаны тут http://www.fastcgi.com/drupal/node/6?q=node/15 Это полезно почитать, чтоб не составлять о FastCGI неверные предпосылки, от которых потом отталкиваться в своей критике, как это сделано у Дмитрия Как видите, в white paper вообще о "скриптах" речи не идет, и основная идея повышения быстродействия там "This solves the CGI performance problem of creating new processes for each request." Да, встроенный fastcgi в PHP не решает проблему быстродействия инициализации скриптов. Не решает, и _не должен_ решать. Глупо критиковать что-то за то, что он не должен сделать. Он решает загрузку кода PHP интерпретатора, инициализации системных библиотек и т.д. - все, что ему и полагается на данном уровне. Что бы ускорить быстродействие конкретного PHP скрипта - FastCGI нужно реализовывать именно внутри самого скрипта, что, в общем, топикстартер, как я понял, и хочет сделать.
Наверно, потому что fcgi бывает не только в скриптовых языках? О чем и я. Преимущество FastCGI в том, что можно написать приложение, которое будет работать постоянно, обрабатывая входящие данные. В реализации для PHP этого сделать нельзя. То что интерпретатор запускается в fcgi мне мало дает радости. скрипты PHP не работают в fastcgi.
Можешь не комментировать, кстати. Привычку придиратся к словам я уже у тебя заметил. Твои замечания абсолютно ничем не помогут ТСу.
флоппик, а мне мало радости, что моя кофеварка не делает минет. Так сказать, неполностью реализует принципы работы, так как тетка, к примеру, может и кофе варить и минет делать. Фастсги в пхп реализует все принципы фастсги. Он инициализирует все, что "ниже", организует луп и исполняет то, что выше много раз. Где разместить эту точку - зависит от задач. Если дмитрий услышал краем уха "фастсги" ускоряет работу PHP и пошел на это ругаться, то это его проблемы. Теперь давайте еще раз прочитаем Интерпретатор PHP - это приложение? - приложение. Он работает постоянно? - постоянно. Входные данные обрабатывает? - обрабатывает. Т.е. делает все то, что полагается. Т.е. можно сказать так... fastcgi ускоряет все, что лежит ниже уровня его реализации. Соответственно, если у нас есть скрипт, и мы хотим ускорить именно этот скрипт - фастсги нужно реализовывать именно на уровне этого скрипта, а не в интерпретаторе. Именно так везде - и в перле, и в руби это и сделано. По-этому мне не понятно, почему вы обвиняя всех в непонимании работы fastcgi говорите, что реализовать такое нельзя, а писать свой скрипт "не нужно". Нужно и более того - это единственный вариант, по которому идут все скриптовые языки. А за встроенный fastcgi более низкого уровня - спасибо, так как он позволяет решить совсем другие проблемы.
ТСу был дан единственно верный совет. Гуглить - может кто создал PHP класс реализующий интерфейс. Если нет - писать этот интерфейс на сокетах самому. И никаких придирок к словам не было бы, если бы Вы изначально говорили о реализациях фастсги на требуемом уровне, а не пытались объяснить - почему же встроенный fastcgi не подходит и более того - вообще "не правильный" фастсги.
Да потому что ПХП - язык программирования, блин. Я не сказал — неправильный. Я сказал - номинальный. У интерпретатора поддержка фастцги есть. У ПХП - как языка программирования, поддержки фастцги — нет. Такая формулировка - верная?
Э... а какие ты знаешь скриптовые языки программирования, у которых есть поддержка fastcgi? Все реализации fastcgi для скриптов - это библиотеки, написанные на том же скриптовом языке, открывающие сокет и принимающие fastcgi запрос. Ни в одном языке такая реализация не встроена в интерпретатор и вообще там ничего специально для такой поддержки не делается... хотя фиг знает... мож где и засунут, дураков много. Так что поддержка фастсги у ПХП - как языка программирования - дело рук самих скриптов. Если называть поддержкой - наличие в официальных репозиториях соответствующих библиотек с нужными классами - то да, в PEAR такой поддержки нет.
Гм, ну давай по-другому.. если ты по-прежнему считаешь, что прав а я придираюсь к словам - скажи, что нужно сделать, что бы в PHP появилась поддержка FastCGI такая же, как в других языках.. как в Perl, допустим - именно это просил ТС. А если ответ будет "ничего сделать уже невозможно" - тогда вопрос - а что такого в Perl сделано для того, что бы там появилсь поддержка FastCGI, чего в PHP сделать нельзя.