Быть или не быть eAccelerator

стоит Linux Centos 5.2 2.6.18-128.1.10.el5PAE #1

Код:

Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies     with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies     with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies

из 4 мозгов загружено было 2,6
нагрузки проца:
Last 1 minute 0.09
Last 5 minutes 0.01
Last 15 minutes 0.06

поставил:

Код:

with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

теперь мозгов 1,6 полегчало тобиш...
но нагрузка на проц выросла не по детски:
Last 1 minute 0.69
Last 5 minutes 0.81
Last 15 minutes 0.56

это нормальная ситуация ? или ну его в баню этот акселератор ?

тоже интересует, поставил на один сервак - вот стоит ли на остальные ставить ?

Стоит ставить на нагруженные машины, где работает много php.

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

Кстати нашел старенький топик про настройку акселераторов и возникающие проблемы

ну тут ценной инфы ноль - нужно смотреть именно на статистику акселератора - сколько свободной памяти у него, по дефолту 32мб

кроме того - мы всегда отключаем сжатие, чтобы проц не расходовал на ненужную по сути операцию, и все что можно - ключи, сессии, конетнт запихиваем в память, в php.ini значение session.save_handler должно быть eaccelerator

также следует правильно настроить апач на предмет
StartServers
MinSpareServers
MaxSpareServers
ServerLimit
MaxClients
MaxRequestsPerChild

btw скрипты зашифрованные зендом он особо оптимизировать не сможет

Ged: PAE ядра это ужос, это сразу потеря 20% производительности, если 4Г памяти - надо ставить x86_64

Mike Fox писал:

btw скрипты зашифрованные зендом он особо оптимизировать не сможет

Как это не сможет? будет дергать их из shared memory а не с диска, причём уже байткод а не исходник, вот тебе и прирост.

Gourad писал:

Как это не сможет? будет дергать их из shared memory а не с диска, причём уже байткод а не исходник, вот тебе и прирост.

То что скрипт лежит в памяти в виде байткода - это не означает, что он оптимизирован, вот года 4 или 5 назад впервые поставил eAccelerator на большую ППЦ на пачку серверов, и тогда он очень лихо прооптимизировал криво написанные скрипты, нагрузка упала раз в пять на каждом.

Скрипты CJ, которые написаны на PHP все зашифрованы зендом и особого прироста производительности при установке eAccelerator'a нет, данные не с потолка, максимум что мне удавалось получить том же прогрессе/стриме - выполнение скрипта 25мс, в среднем около 30мс. А вот выполнение скрипта на сях занимает 3-4мс, и мало кто знает - скорость запуска скрипта на сях тоже можно оптимизировать.

Mike Fox писал:

То что скрипт лежит в памяти в виде байткода - это не означает, что он оптимизирован, вот года 4 или 5 назад впервые поставил eAccelerator на большую ППЦ на пачку серверов, и тогда он очень лихо прооптимизировал криво написанные скрипты, нагрузка упала раз в пять на каждом. Скрипты CJ, которые написаны на PHP все зашифрованы зендом и особого прироста производительности при установке eAccelerator'a нет, данные не с потолка, максимум что мне удавалось получить том же прогрессе/стриме - выполнение скрипта 25мс, в среднем около 30мс. А вот выполнение скрипта на сях занимает 3-4мс, и мало кто знает - скорость запуска скрипта на сях тоже можно оптимизировать.

Ыхыхыхы, что там "оптимизировать"? Кто-то до сих пор верит в байку, что Зенд Оптимайзер что-то там "оптимизирует"? Ну да, там есть проходы оптимизации байткода, которые были актуальны во времена пхп4 (да и время выполнения этих проходов сравнимо с оверхедом на выполнение неоптимизированного байткода). А сделана эта нанооптимизация была именно для того, чтобы хостеры, не особо понимающие внутренности Зенд Енджайн (коих подавляющиее большинство) установили ЗО в надежде сэкономить системные ресурсы, основная функция которого, разумеется, это запуск криптованных Зенд-енкодером скриптов.

Собственно, акселераторы (неважно, ЕА, XCache, APC) что делают. Они кэшируют байткод (удивительно!). Если (вдруг) кто занимался написанием компиляторов то прекрасно знает, что самая тяжеловесная операция - это лексический парсер. Так вот чтобы получить байткод, PHP без акселератора выполняет на КАЖДЫЙ запрос две весьма тяжелые операции: лексический парсинг исходного кода в дерево и построение из этого дерева байткода. Акселератор же кэширует полученный байткод (в шаред мемори; то, что не влезает - на диске). И получаемая за этот счет экономия системных ресурсов вообще несравнима с мифической "оптимизацией" байткода (которая давно уже неактуальна, ср. дамп опкодов php4.3 и 5.3).

Запуск скриптов, закодированных ZO - отдельная тема: заенкоденный .php уже содержит именно байткод (только зашифрованный и загзипованный), а распаковка и расшифровка - операция значительно более дешевая, чем лексер, так что в этом конкретном случае, действительно, толку не так уж и много.

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

А что касается сей - ну понятное дело, что если запускаешь как CGI, то куча ресурсов уйдет на fork+exec. man fastcgi, какбэ.

Gourad: еще раз попробую растолковать свою мысль - оптимизация и кэширование это разные вещи, в eA на это даже разные директивы, собственно готовый байткод от ZO он особо оптимизировать не может, но может кэшировать. Суть не меняется, мегаприроста производительности нет, но запихнуть все php файлы на сервере в память стоит;

По поводу сей - и без fastcgi можно сделать все хорошо, стандартными средствами linux. Я уверен в bsd системах что-то подобное тоже есть, так как есть на MacOS X.

Упор в еА какраз делается не на оптимизацию, а на кеширование байткода.
Зачем интерпретировать одно и тоже много раз, если можно один раз отработать и потом просто тягать из кеша.

Уже больше года стоит eAccelerator на паре личных серверов, кеш только в оперативке, на диск не делаем, апач стоит без ngnix. Эфект отличный! ставить по любому нужно если есть php скрипты к которым часто обращаются(да впринципе даже и если не часто то тоже лишним не будет) так как даже "на глаз" заметен прирост скорости.

Gourad: +1

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

да и что тут оптимизировать если Last 15 minutes 0.06 ?

где хорошо виден Eacc - так это если в проекте условно 150 пхп файлов без зенда, которые инклудяться где-то.

Mike Fox писал:

То что скрипт лежит в памяти в виде байткода - это не означает, что он оптимизирован, вот года 4 или 5 назад впервые поставил eAccelerator на большую ППЦ на пачку серверов, и тогда он очень лихо прооптимизировал криво написанные скрипты, нагрузка упала раз в пять на каждом. Скрипты CJ, которые написаны на PHP все зашифрованы зендом и особого прироста производительности при установке eAccelerator'a нет, данные не с потолка, максимум что мне удавалось получить том же прогрессе/стриме - выполнение скрипта 25мс, в среднем около 30мс. А вот выполнение скрипта на сях занимает 3-4мс, и мало кто знает - скорость запуска скрипта на сях тоже можно оптимизировать.

А си у Вас из цыги апачем форкается ?
И не перлтуси случайно Ваш си?
Насчет сиджа незнаю но один програмер мне как то подогнал перлтуси

Ged писал:

стоит Linux Centos 5.2 2.6.18-128.1.10.el5PAE #1 Код: Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies     with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies     with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies из 4 мозгов загружено было 2,6 нагрузки проца: Last 1 minute 0.09 Last 5 minutes 0.01 Last 15 minutes 0.06 поставил: Код: with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator теперь мозгов 1,6 полегчало тобиш... но нагрузка на проц выросла не по детски: Last 1 minute 0.69 Last 5 minutes 0.81 Last 15 minutes 0.56 это нормальная ситуация ? или ну его в баню этот акселератор ?

А покажите опции с которыми был собран php в мемент тестирования ... а то будет как прошлый раз (http://www.opennet.ru/openforum/vsluhforumID3/4712.html левый фактор кардинально меняет результат тестирования)