Новая тема   Ответить

 Ged
стоит Linux Centos 5.2 2.6.18-128.1.10.el5PAE #1
Код:

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

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

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

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

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

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

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

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

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

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

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

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

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

 Mike Fox
Gourad писал:

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

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

 Gourad
Mike Fox писал:

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

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

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

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

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

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

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

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

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

 LemonS
Gourad: +1

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

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

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

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

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