Какой кэшер кода операции PHP мне следует использовать для повышения производительности?[закрыто]

Question

Я пытаюсь повысить производительность при высокой нагрузке и хотел бы реализовать кэширование кода операции.Что из следующего я должен использовать?

• БТР - Руководство по установке
• Ускоритель - Руководство по установке
• XCache ( кэширование ) - Руководство по установке

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

В настоящее время работает на стандартном Debian Etch с Apache 2 и PHP 5.2

[Обновление 1]

Добавлены ссылки на установку HowToForge

[Обновление 2]

Основываясь на полученных ответах и отзывах, я протестировал все 3 реализации, используя следующий план тестирования Apache JMeter в моем приложении:

• Вход
• Доступ к домашней странице

При 50 одновременных подключениях результаты выглядят следующим образом:

Нет кэширования кода операции

БТР

Ускоритель

XCache ( кэширование )

График производительности (чем меньше, тем лучше)

Судя по приведенным выше результатам, eAccelerator имеет небольшое преимущество в производительности по сравнению с APC и XCache.Однако, что наиболее важно из приведенных выше данных, так это то, что любой вид кэширования кода операции дает огромный прирост производительности.

Я решил использовать APC по следующим двум причинам:

• Пакет доступен в официальном репозитории Debian
• Более функциональная панель управления

Чтобы подвести итог моему опыту:

Простота установки:APC > eAccelerator > XCache
Производительность:Ускоритель > APC, XCache
Панель управления:APC > XCache > Ускоритель

Answer 1

Я думаю, что ответ может зависеть от типа веб-приложений, которые вы используете.Я должен был сам принять это решение два года назад и не мог выбрать между Zend Optimizer и eAccelerator.

Чтобы принять решение, я использовал ab (apache bench) для тестирования сервера и протестировал три комбинации (zend, eaccelerator, обе запущены) и доказал, что eAccelerator сам по себе обеспечивает наибольшую производительность.

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

Answer 2

Я использую APC, потому что его было легко установить в Windows, и я разрабатываю на WAMP.

Интеграция APC в PHP6 обсуждалась здесь:http://www.php.net /~derick/meeting-notes.html#добавить кэш кода операции в apc-дистрибутив

И здесь есть инструкции по установке APC на Debian Etch:http://www.howtoforge.com/apc-php5-apache2-debian-etch

Answer 3

Я запустил несколько бенчмарки с eAcclerator, APC, XCache, и Zend Optimizer (хотя Zend - это оптимизатор, а не кэш).

Контрольные результаты http://blogs.interdose.com/dominik/wp-content/uploads/2008/04/opcode_wordpress.png

Результат:eAccelerator является самым быстрым (во всех тестах), за ним следуют XCache и APC.(Единица на диаграмме - это количество секунд, затрачиваемое на вызов домашней страницы WordPress 10 000 раз).

Оптимизатор Zend сделал все медленнее (!).

Answer 4

Я не могу сказать вам наверняка, но место, где я сейчас работаю, изучает APC и eAccelerator.Однако это может повлиять на вас - APC будет интегрирован в будущую версию PHP (спасибо Эду Хаберу за ссылку).

Answer 5

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

Answer 6

Я использую XCache уже больше года без каких-либо проблем.

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

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

Answer 7

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

Поэтому я бы сказал:

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

Но я бы сказал:

1. Убедитесь, что это ДЕЙСТВИТЕЛЬНО синтаксический анализ PHP-кода, который вызывает проблемы с производительностью, путем профилирования вашего приложения.Я думаю, что весьма вероятно, что это не так - в этом случае вы напрасно потратили бы свое время (фактически, использовали бы его негативно продуктивно), установив любой из них.