Сведения о вопросе

Gentleman

21:02, 27th August, 2020

Теги

php   performance   caching    

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

Просмотров: 526   Ответов: 7

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

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

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

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

HowtoForge добавлены установочные ссылки

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

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

  • Авторизоваться
  • Доступ К Домашней Странице

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

Нет Кэширования Кода Операции
No Opcode Caching

APC
APC

eAccelerator
eAccelerator

XCache
XCache

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

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

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

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

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

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



  Сведения об ответе

9090

02:32, 17th August, 2020

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

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

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


  Сведения об ответе

lourence

21:37, 5th August, 2020

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

Интеграция APC в PHP6 обсуждалась здесь: http://www.php.net/~derick/meeting-notes.html#add-an-opcode-cache-to-the-distribution-apc

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


  Сведения об ответе

appple

00:08, 3rd August, 2020

Я запустил несколько тестов с 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 Optimizer сделал все медленнее (!).


  Сведения об ответе

VERSUION

07:04, 1st August, 2020

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


  Сведения об ответе

darknet

04:24, 22nd August, 2020

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


  Сведения об ответе

ЯЯ__4

07:54, 28th August, 2020

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

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

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


  Сведения об ответе

ASER

19:39, 28th August, 2020

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

Так я бы сказал:

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

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

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


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться