>Можно ли использовать несколько дновременно?

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

Да я тоже искал ответ

Да я тоже искал ответ на этот вопрос , спасибо.

http://ufacode.ru/blog/programming/43.html

Но нада еще инфочки..

Давайте разведем полемику и демагогию на этот счет.

А еще Nginx может ускорить работу PHP или нет?

>http://ufacode.ru/blog/programming/43.html
Если это для тебя информация, то у меня для тебя плохие новости.

А еще Nginx может ускорить работу PHP или нет?

nginx этим не занимается, но если у тебя высокие нагрузки, то он может серьёзно помочь. Ну и можно тупо кэшировать сгенерированный HTML, но к пхп это опять не имеет отношения.

Связка PHP-FPM + nginx будет однозначно быстрее, нежели PHP+apache+mod_php+nginx. Но она имеет ряд ограничений, а потому использовать её на хостинге не выйдет. Это решение только для тяжелых проектов.

Если у вас один большой проект который требуется ускорять, то советую пересобрать PHP без лишнего мусора. Потребление памяти уменьшится в несколько раз, если выкинуть лишний функционал.

Ещё не стоит забывать о том, что применять надо обязательно стабильные версии ветки 5.3, и ни в коем случае 5.2. Не смотря на некоторые проблемы с сегфолтами при разработке, новый сборщик мусора работает в разы лучше старого. А значит код который живет в памяти долго работает намного стабильнее.

Что касается акселераторов - я лично использую XCache, то только из за встроенного дебаггера. Тут нужно попробовать разные и выбирать. Единственное что - пропреоретарщина очень плохо работает с патчами вроде Suhosin, а потому не нужна.

Опять же если у вас большой проект, то например функцию загрузки файлов можно реализовать используя модули для nginx.

Ну и последнее - кэширование, кэширование, кэширование.

x3al & anonymous спс!!

через fcgi cache

Но она имеет ряд ограничений, а потому использовать её на хостинге не выйдет. Это решение только для тяжелых проектов.

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

пересобрать PHP без лишнего мусора. Потребление памяти уменьшится в несколько раз, если выкинуть лишний функционал.

если php модульная, то можно просто extension= закомментировать ненужные в php.ini

надо обязательно стабильные версии ветки 5.3, и ни в коем случае 5.2

аргументы? мне тоже больше нравится 5.3, но 5.2 еще поддерживается, кроме того, не все еще готовы перейти на 5,3 , например сухосин

Несколько лет назад сидел на eaccelerator, пока тот в одной из версий не стал путать одноимённые скрипты в разных хостах. Перелез на apc, благо, он сейчас позиционируется как официальный.

Зимой его, apc, стабильная версия вдруг стала убивать PHP 5.3 под высокой нагрузкой. Ругань в логах на невозможность выделить память, много ругани в Интернете по этому поводу... Откатился на предыдущую, и сидел на ней почти до нового года, пока она перестала поддерживаться с новыми PHP-слотами в Gentoo.

После этого пересел на xcache. Недели три на двух высоконагруженных проектах, полёт нормальный.

А по скорости они все ± похожи...

eAccelerator (последняя версия) же вроде использует кеш по абсолютному пути к скрипту, если только хосты не сидят в chroot песочницах с идентичным окружением, то путать не должен

с APC у меня получилось то же самое

с XCache впечатление что памяти ест уж чересчур много..

>подробности? почему не выйдет и почему для тяжелых? какие ограничения? Я говорил про сервера под хостинг. Ряд быдлокода использует особенности окружения, а значит 100% кода не заработает Я не могу привести примеры того что сейчас не работает на этой связке. Но когда мы переводили форум (vbulletin) год назад, то возникали некоторые проблемы при работе «из коробки». Движек по магической причине кормил пользователям свои исходники. Пересобрали PHP и репозитория все заработало, почему не работало: вопрос.

Если ты держишь свои проекты - то да, можно пофиксить и дописать. Но если ты хотел - то так не выйдет.

если php модульная, то можно просто закомментировать ненужные

Кроме в модулей существует ещё и другой код: pcntl например. Список флагов можно посмотреть в сорцах.

аргументы?

Все очень просто. Я пишу на PHP демоны и долгоиграющие скрипты. Разница в потреблении ресурсов между 5.2 и 5.3 огромная. На 5.2 поток брутфорсера через час работы кушает 100 мегабайт, и далее количество потребляемой памяти продолжает рости. На 5.3 он остается в рамках своих 20-30 мб, пусть хоть целый день работает. Уверен, что с обычными скриптами все так же, но только в меньших масштабах.

И да, я понимаю что все работать на 5.3 не будет, но при возможности надо обязательно на него переходить.

например сухосин

PHP Version 5.3.3-1ubuntu9.3
This server is protected with the Suhosin Patch 0.9.9.1

Точно точно?

Да, у меня вместе с ним на 5.3 не работал Zend Optimizer. Но когда я изменил уровень оптимизации - все заработало.

Ну вы понели.
Я криворукий мудак не переключивший режим разметки.

> Что из них лучше

да все равно в общем-то, но тебе проще водрузить eAccelertor. в твоем случае снизится потребление памяти скриптами (раза в два) и чуть лучше скорость будет...

А еще Nginx может ускорить работу PHP или нет?

он ускорит отдачу статики.. может быть уменьшит в какой-то мере потребление памяти, следовательно и ПХП чуть полегче станет...


2anonymous (16.01.2011 3:16:21)

Связка PHP-FPM + nginx будет однозначно быстрее, нежели PHP+apache+mod_php+nginx.

далеко не факт

Лучший пхп оптимизатор - Python.

Оптимизирыет не только скорость работы, но еще и время разроботки.

далеко не факт

Установите и проверьте.

nginx в любом случае необходимо использовать для отдачи статики. Либо любой другой легковесный сервер. Отдавать статику апачем - моветон.
Если убрать прослойку в виде mod_php и самого апача быстродействие заметно возрастает.

Опять же я говорю о больших нагруженных проектах.
Если ставить связку на домашнюю страничку с 100 хостами, то работать быстрее врядли будет.
Но я думаю все тут знают, что апач любитель памяти. И как он её пожирает при уже 100 активных пользователях.

/dev/brain вот единственный акселератор

Ок. Дайте мне форумный движек уровня xenforo на питоне. А потом CMS с количеством расширений как у wordpress.

Продолжайте ездить в магазин на своем билазе, это ведь очень удобно.

Ставьте тот, который в вашем дистрибутиве. Обычно это xcache, eaccelerator, apc.

> А еще Nginx может ускорить работу PHP или нет?

У вас каша в голове. Почитайте, что такое FCGI.

Nginx позволяет тратить меньше памяти на большое количество соединений, keep-alive, хорошо работает со статикой. За счет этого php-процесс может получить больше ресурсов, по сравнению с апачевской конфигурацией. Хотя если ставить апач на бакенде, с ограниченным количеством процессов, а nginx на фронтенде для статики, то результат будет похожим. Еще nginx позволяет кешировать ответы скриптов, а также отдавать результаты из memcached. Но этим вам точно рано заниматься, если даже акселератора не настроили.

> Установите и проверьте.

а че проверять когда полно обзоров и тестов? да и устанавливаю я их уже черти-сколько лет (fcgi)
прирост в скорости будет только при оптимальном подборе воркеров и достаточном кол-ве ядер. ведь преимущества fcgi (php-fpm как улучшенная реализация всего лишь) далеко не в скорости выполнения, она один хрен почти одинакова что так, что эдак.
на дохлом вдс об одном ядре «PHP+apache+mod_php+nginx» будет быстрей php-fpm (на чисто скриптах), хоть при 10ти пользователях, хоть при тысяче..
всегда убивает (точнее убивал бы) когда кто-то заявляет подобную чушь, мол php-fpm быстрей. да нихрена он не быстрей, вот установите и проверьте (c)

Ну, извините. Я думал вы разработчик.

CMS на питоне конечно есть, причем их много. Посмотрите, я тут не советник.

/dev/brain вот единственный акселератор

bash: /dev/brain: Нет такого файла или каталога

:)

Quercus.

при тестировании Mediawiki и Drupal, Quercus оказался быстрее стандартного mod_php в 4 раза, продемонстрировав скорость близкую к mod_php с включенным акселератором APC.

http://www.opennet.ru/opennews/art.shtml?num=21264

>продемонстрировав скорость близкую к mod_php с включенным акселератором APC

Что есть шило на мыло.

Гораздо интереснее оценить коммерческий Quercus, который компилирует PHP в байткод JVM. Но я нигде не нашёл тестов его производительности.

А так - решение интересное. Но пока не сделают вменяемый трейс ошибок - не более, чем игрушка. При ошибке в PHP вываливается стек JVM. Ни PHP-файла, в котором возникла ошибка, ни номера строки... Работать невозможно.