Скомпилированный PHP?

Ответ 1

Обратите внимание, что Zend Optimizer и MMCache (или аналогичные приложения) - это совершенно разные вещи. В то время как Zend Optimizer пытается оптимизировать программный код операции, MMCache будет кэшировать скрипты в памяти и повторно использовать предварительно скомпилированный код.

Несколько лет назад я сделал несколько тестов, и вы можете найти результаты в моем блоге (на немецком языке). Основные результаты:

Когда дело доходит до кешей: * fastest: eAccelerator * XCache * APC

И: вы хотите установить кеш-код операции!

Например: alt text http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png

Это время, которое потребовалось, чтобы вызвать домашнюю страницу wordpress 10.000 раз.

Изменить: BTW, eAccelerator содержит сам оптимизатор.

Ответ 2

MMCache устарел. Я рекомендую http://pecl.php.net/package/APC или http://xcache.lighttpd.net/, оба из которых также дают вам переменную память (например, Memcache).

Ответ 3

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

Любой огромный веб-сайт, работающий с PHP (например, Facebook), запускает какую-то систему кэширования кода операции, такую ​​как MMCache.

Проблема в том, что их не очень легко настроить в зависимости от вашей системы.

Ответ 4

В зависимости от того, какая часть вашего PHP-кода действительно выполняется и как долго выполняется это выполнение, может быть действительно большой победой. Это, конечно, не повредит, но выигрыш, который вы видите, очень сильно зависит от того, где ваше время в настоящее время потрачено.

btw mmcache теперь запущен в другой проект, я забыл имя, но Google скажет вам.

Ответ 5

Я использую APC на своих производственных серверах, и он работает очень хорошо из коробки. Скомпилируйте его и добавьте его в PHP, и для него не так много настроек. Я проверяю его раз в то время, просто просматривая статистику, но поскольку я использую MVC, все основные файлы (маршрутизаторы, контроллеры и т.д.) Редко меняются каждый день, поэтому код остается компилированным и работает довольно эффективно,

Ответ 6

В настоящее время мы используем apc, бесплатно и просто подключаем и играем на наших серверах. Обеспечило огромное увеличение производительности для нашего сайта, особенно по мере увеличения размера проекта. У меня также отключен apc.stat, поэтому он не проверяет, обновлен ли код, поэтому всякий раз, когда нам нужно обновлять код на реальном сайте, мы перезапускаем apache.

Ответ 7

Я использую APC и могу подтвердить, что он может значительно снизить нагрузку на CPU и I/O на сервер приложений, если вы поддерживаете высокий уровень кэширования. Это не только избавит вас от необходимости компиляции, но и избавит вас от необходимости читать php файлы с диска. (т.е. байт-коды обслуживаются непосредственно из основной памяти, поэтому они очень быстрые). Он снижает скорость отображения одной страницы и увеличивает количество запросов в секунду, которое может обрабатывать ваш сервер.

Если вы используете RedHat или CentOS, установка APC очень проста:

yum install php-devel httpd-devel php-pear
pecl install apc 
echo "extension=apc.so" > /etc/php.d/apc.ini
# if you're using SELinux:
chcon "system_u:object_r:textrel_shlib_t" /usr/lib/php/modules/apc.so
/etc/init.d/httpd restart

Ты спросил о недостатках. Единственным недостатком является то, что для этого требуется некоторая память. Значение по умолчанию для APC составляет 30 МБ, но его можно отрегулировать, а стоимость небольшого объема памяти больше, чем платит за себя с увеличением скорости и скорости ответа.

Ответ 8

Тестирование BlaM включало все вызовы БД, сделанные WordPress. Когда вы делаете меньше вызовов БД, вы увидите, что увеличение производительности кэшей операций операций будет еще более драматичным.

Ответ 9

Вы проверили Phalanger? Он компилирует код PHP в .NET. Ниже приведены некоторые тесты, которые показывают, что это может значительно повысить производительность.

Ответ 10

Я использовал Zend Accelerator немного назад в течение дня (2004-й). Это, безусловно, дало некоторые существенные выигрыши в производительности по коду, с которым он мог работать, но, к сожалению, система, которую я использовал, была разработана для довольно часто динамически загружать код, а затем оценивать его, что Zend Accelerator не мог сделать много в то время (и я, d до сих пор не может).

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

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