eAccelerator vagy APC (Alternative PHP Cache) vagy XCache?

Debian GNU/Linux

Sziasztok!

Melyik PHP cacher-t erdemes hasznalni a harom kozul? Van tapasztalatotok valamelyikkel? Erdemes egyaltalan cacher-t hasznalni?

  • 4261 megtekintés

Nincs. Tobb Debianos hosting gepen is megy, php5 alatt eacc. Meg php4 alatt is. Forumok, wordpress meg hasonlok is mennek vele. Eacc forras, php5 es php4 meg vegyesen, van ahol forras, van, ahol deb csomag.

Hopp, lejjebb nezem. Tenyleg, 5.2 a max. php, amit hasznalunk eacc cache-sel.

Ui: most vettem eszre, milyen regi topic :) Bocs.
Amugy shm size nalunk is 8M korul van, viszont a tenyleges cache ramdisken van (128-256M) es egy script atime alapjan torolgeti a regi bejegyzeseket.

--
http://www.micros~1

"eAccelerator is still under development. The latest release, 0.9.5.2, supports PHP 4 and all PHP 5 releases including 5.2. In older releases, the encoder will only work with PHP versions from the 4.x.x branch. eAccelerator will not work with any other versions of PHP."
--
Why does that command take that long?

( zwei | 2008. 05. 17., szo – 22:54 )

Eaccelerátor nekem bevált.
Érdemes haználni ilyeneket, mert csökkenti a cpu terhelést, és jobb válaszidőket produkál a szerver.
Negatív tapasztalatom még nem volt.

Nalam eAcc van font, de nem tul agyonterhelt es nem tul produktiv szerveren. Eddig gond nem volt vele, csak neki kell allnom egy joval terheltebb produktiv szerver felepitesenek, es gondoltam megkerdezem, kinek milyen tapasztalata van melyik gyorsitoval.

--
Why does that command take that long?

Nekem a legnagyobb forgalmú webszerver havi átlag 150 000 egyedi látogatót (15-16M hit/hó) visz. Eaccelerátor van alatta php4-el, egy dual opteront 20-25%ra hajt ki processzorban. Eacc nélkül ez több mint dupla ekkora cpu terhelés lenne.

utólagos pontosítás: két darab duál opteront.

eAcc konfigrol kerdezhetek? Nalam a kovetkezok vannak beallitva: 


extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.log_file = "/var/log/apache2/eaccelerator_log"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="120"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

Nem lesz agyonterhelve a dolog, kb 20 domain, foleg wordpress, jommla es egyedi fejlesztesu php oldalak. Apache2, php 5.2.0-8+etch11, 1G ram. Miket erdemes beallitani? Annak idejen olvasgattam kemenyen a WIKI-t, es ezt szurtem le belole.

--
Why does that command take that long?

de, a produktivon valoszinuleg keves lesz, ezert kerdeztem, hogy a fenti parameterek mellett milyen ertekeket javasolnatok. Ezzel a beallitassal egy kb 0 terhelesu szerver fut, tulajdonkeppen homokozo jelleggel. Itt jelenleg igy alakul a 16M kihasznaltsaga:
Memory usage 0.30% (0.05MB/ 16.00MB)
Free memory 15.95MB

--
Why does that command take that long?

compress_level-t nem nagyon szoktam 5-6 nál többre beállítani. Sokkal jobban nem tömörít a 9, viszont több cpu-t eszik. Ha van memória bőven, akkor elég az 5-6 is.
eaccelerator.shm_size akár a 16M is elég lehet. Attól függ, mennyi php kód van a szerveren.
Nálam per pillanat 336 script van cache-elve és 13M-et eszik.
Érdemes időnként ellenőrizni a telítettségét (eleinte naponta, utána ritkábban), és annak megfelelően hangolni.
Persze

( Vudumen | 2008. 05. 17., szo – 23:32 )

eacc egyertelmuen. apc-tol csomo minden meghulyul. eaccnal arra kell vigyazni, hogy az optimizert ki kell kapcsolni mert nem fognak rendesen mukodni az exceptionok.

( p_takika | 2008. 05. 18., v – 10:47 )

Koszonom a valaszokat, akkor megtartom az eAcc-t.
Egy utolso kerdes: 1G rambol, ha 150M-ot adok az eleg, sok vagy keves?

--
Why does that command take that long?

( mogorva v | 2008. 05. 23., p – 21:25 )

Szomorúan tapasztaltam, hogy debian etch-hez se eaccelerator, se xcache nincs.

Látjátok bármi veszélyét, hogy éles környezetbe házilag fordított eaccelerator kerüljön?

( mogorva v | 2008. 05. 27., k – 12:26 )

Na kérem.
Forgattam xcache-et, de nem látom a javulást.
Vannak mindenféle vhostok, webáruházak, kutyafüle.
64 megás az xcache.size és az xcache.var_size is.

Van éppen 525 bekesselt oldal a statisztika szerint, de var-t gyakorlatilag nem is kessel (0). A webáruházak mennek a saját régi tempójukban és a squirrel is ugyan olyan tetü lassú, mint eddig.

extension=xcache.so
xcache.admin.user = "xxx"
xcache.admin.pass = "xxx"
xcache.optimizer = On
xcache.cacher = On
xcache.size = 64M
xcache.gc_interval = 43200
xcache.var_size = 64M

Mit kellene még állítani rajta, hogy érezzem is a kesselést?

Javulást max a processzorterhelés grafikonján láthatsz.
Ha eddig ment 50%-on, akkor most megy pl. 35%-on.
Gyorsabb az alkalmazás csak abban az esetben lesz, ha a cpud 90+ %-al le volt terhelve.
Gyakorlatilag a php kód minden egyes alkalommal történő fordítását takarítod meg vele.

Ok, tudom, hogy van optimizer is, de még egyszer sem tapasztaltam látványos gyorsulást.
Szerintem egy gyorsabb CPU jóval többet dob a lassú php kód futási sebességén.

Aham, én is vmi hasonlótól tartottam, csak minden cache halálra hype-olja magát a saját weblapján (naná, majd nem), hogy mennyire állat lesz tőle minden és lerobban a fejem a sebességtől. Aztán persze a valóság más, de ennyire jelentéktelen változást azért még én sem vártam.

Különben főleg a squirrel-t akartam begyorsítani, de attól tartok az imap kapcsolat lesz lassú (dovecot-tal van párban).

( goddethroned | 2008. 05. 27., k – 19:08 )

Anno mi is szerettük volna használni valamelyiket. Amit próbáltam:

xcache
eaccelerator
apc
zend optimizer

a kód egy php4-ben kezdett cucc, ami aztán portolva lett php5-re, a tesztek php5-el történtek. A site napi 15-20e látogatót szolgál ki.

A sajnálatos tapasztalat, hogy az első 3 kb 20 perc üzem után minden esetben összefosta magát, egyszer csak elkezdtek rossz értékek megjelenni a számításoknál, nem generálta le az oldalt, efféle hibák voltak.

Az egyetlen cucc amivel nem volt negatív tapasztalat, az a Zend féle megoldás.

Amúgy kb ugyanazt tudta mindegyik gyorsítás szempontjából, a szerver terhelésre már nem emlékszem, de a req/sec több mint 10x nagyobb lett ab2 tesztprogrammal nézve mint gyorsítás nélkül

Szóval én csakis a Zendre szavazok, sajnos a kódoló részért ugye fizetni kell :(

Még valami:

A Zend volt az egyetlen cucc, ami képes volt !!bármilyen!! eddig általam írt forrást sikeresen kódolni. A másik három megint csak kivétel nélkül elhasalt az én projektjeimnél.

( maszili | 2008. 05. 27., k – 19:44 )

regota hibamentesen mukodik...

    * debian etch (64bit)
    * php 5.2.0-8+etch10
    * eaccelerator 0.9.5.2
    * napi ~10000 latogato

--
maszili

( turul16 v | 2008. 05. 27., k – 19:56 )

Honnan tudjak mikor lesz invalid/oreg egy adat ?

( Kayapo | 2008. 05. 27., k – 21:35 )

Nekem ez van fenn:
lighttpd-1.4.19 (ssl) - a light and fast webserver
PHP 5.2.0-8+etch11 (cgi-fcgi) (built: May 10 2008 10:41:01)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2007, by Zend Technologies
with Zend Optimizer v3.3.0, Copyright (c) 1998-2007, by Zend Technologies
Percenként 20-80 oldalletöltéssel (tudom, hogy ez nem egy oriási terhelés) és megy mint a mozdony
----
Nyicc-egy-csört?
Esetleg nézd meg itt: http://kayapo.dyn.hu/

( uniquevisitor | 2011. 02. 11., p – 15:52 )

Sziasztok,

Változott valamit a helyzet ezekkel a programokkal kapcsolatban? Nekem most kellene választanom ezek közül. Nincs nagy forgalom, csak kicsi a vps processzor és nagy a magento terhelése.

köszi

( rootkit | 2011. 02. 11., p – 16:59 )

Nekem az eacc évek óta megy rendesen, 7 országban, ebből két oldal napi 50ezer egyedi felett, elég szép terheléssel. Mindig forrásból telepítem az eacc-t.
linux + nginx + php5.2fcgi + eaccelerator-0.9.5.3
Csak opcode-cache-t használok, az optimizer-t kapcsoljátok ki, mert bug-os!
Alap config (lehet emelni az shm értéket 64-re bátran):

eaccelerator.shm_size="32"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="0"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="0"
eaccelerator.compress_level="0"

( wladek1 | 2011. 02. 12., szo – 21:20 )

eAccelerator 0.9.6.1 shm only 3600 prune period, without compression
Arra kell odafigyelni, hogy az shm -be beleferj, kulonben kapsz egy fataliganyi errort...:)