ugrás a tartalomhoz

Zend Optimizer: hamisan failed to open stream hibát ad

vbence · 2007. Aug. 13. (H), 21.46
Üdv!

Már többször jelentkezett a probléma, de sosem sikerült a végére járnom. Ha mondjuk ftp-n keresztül frissítem a fájlokat a szerveren a szerver néha elkezd failed to open stream: No such file or directory ... hibákat dobálni olyan fájlokra, amik a helyükön vannak (jogok is rendben).

Apache újraindítás sem sokat segít ilyenkor.

Gondolom az optimizernek érzékelnie kellene, ha a fájlok tartalma megváltozik, szóval ez elég bug-szagú dolog.

Kéne törölni valami fájlokat?

B
 
1

optimizer hasznossága

Hodicska Gergely · 2007. Aug. 14. (K), 15.54
Általában az optimizerek szoktak okozni elég vad hibákat, ezért annyira nem is szeretem őket, tekintve, hogy általában csak nagyon minimális teljesítmény pluszt tudnak elérni. Pl. eaccelerator esetén volt olyan para, hogy bekapcsolt optimizer esetén nem tudtad elkapni a kivételeket catch ágban.


Üdv,
Felhő
2

Lehet,

vbence · 2007. Aug. 15. (Sze), 09.54
Lehet, hogy csak a kis lelkemnek megnyugtató. Valahogy borsózik a hátam attól a gondolattól, hogy minden egyes kéréskor le kell fordítani a szripteket.

Benyomok egy error logot, ha még mindig produkálja a dolgot, azt hizsem még is meg kell barátkoznom a gondolattal.
3

optimizer nem az opcode cache

Hodicska Gergely · 2007. Aug. 15. (Sze), 11.23
A fordítás kiküszöbölését az opcode cache végzi. Az optimizer már ezzel a byte kóddal dolgozik, ezt optimalizálja. Pl. van három kiírás utasításod, akkor abból csinál egyet a szövegeket összeolvasztva, ami részben időigényes. Ezért is van az, hogy az optimizert nem érdemes opcode cache nélkül használni, mert az optimalizálás több időt vehet igénybe, mint amit nyersz vele.


Üdv,
Felhő
4

Valóban

vbence · 2007. Aug. 15. (Sze), 12.06
Nekem valamiért egyértelmű volt, hogy opcode cache (is) van benne. Tudnál ajánlani valami használható cache-t?

Zseniális php erőforrás figyelőmmel fel is tűnt, hogy az optimizerrel több ideig futnak a kódok, de gondoltam a cache-elés ellensúlyozza ezt... így valóban nincs sok értelme.
5

eaccelerator, apc

Hodicska Gergely · 2007. Aug. 16. (Cs), 01.12
Manapság talán ez a két legjobb cucc. Az előbbivel valamikor volt gond talán suhosin adott verziója esetén (xcache ment akkor jól), de mostanában nincs vele gond. Én az utóbbit is nagyon szívesen használám, de még élesben nem jött össze. Annyit érdemes lehet róla tudni, hogy többek között a PHP fejlesztés felsőfokon című könyv szerzője és PHP atyja fejleszti, és pl. a Yahoo is ezt használja. Ami talán mellette szólna még az az, hogy nyújt olyan extra szolgáltatásokat, mint változó memóriába pakolása kérések között, vagy például 5.2 óta lehetséges upload hook, amivel egyszerűen (patch nélkül) lehet upload progressbart csinálni.


Üdv,
Felhő
6

eaccelerator

Balogh Tibor · 2007. Aug. 16. (Cs), 10.40
Az eaccelerator a 4.x php alatt stabilan működik. Az 5.x verzió alatt voltak/vannak problémák.
7

PHP 4 → múzeum

janoszen · 2007. Aug. 16. (Cs), 11.41
Tekintve hogy a PHP 4 év végétől muzeális darab lesz, ez nem igazán ad okot az örömre.
10

PHP4 múzeum?

Balogh Tibor · 2007. Aug. 17. (P), 09.46
Én azért nem temetném a PHP4-et, bár ha a Zend fickók szándéka ez, és a kezükben a lapát, akkor már nincs mit tenni.

Egyébként sem akkora nagy ugrás a PHP5. Főleg ha figyelembe vesszük, hogy a PHP5 lassabban fut, mint az előző verzió.

De az eAcceleratornál támogatják a PHP5 verziót, csak súlyos hibák jelentkeztek régebben az 5 verzió alatt.
11

Fejlődés...

janoszen · 2007. Aug. 17. (P), 10.24
Én úgy látom, hogy a PHP határozottan halad az OOP irányba, ami ellen nekem semmi kifogásom nincs és a hardver árak csökkenése még inkább világossá tette: a gép erőforrás olcsóbb, mint a szakképzett, jó munkaerő. A PHP 5 szerintem egy jó eszköz a hatékonyság növelésre. Együtt azzal, hogy a PHP 4 megszűnik, szerintem most már valami PHP 4-es dologba belekezdeni nem éppen tanácsos.
12

Feljlődés

Balogh Tibor · 2007. Aug. 17. (P), 11.08
Együtt azzal, hogy a PHP 4 megszűnik, szerintem most már valami PHP 4-es dologba belekezdeni nem éppen tanácsos.


Azért a php4 és php5 között nem áthidalhatatlan szakadék található. :)

Mint például a Drupál és hasonló kódok is mutatják, nem az a helyzet, hogy az OOP jó, minden egyéb rossz. Most meg jön a következő szajkóznivaló, hogy php5 jó, php4 rossz.

Ezzel nem azt akarom mondani, hogy márpedig maradjunk minden esetben valami előző verziónál, bármi légyen is az. De ne írjunk már úgy a php5-ről mintha az univerzum, de minimum a világunk megváltása függene tőle.

Na jó, van benne egy halom függvény, amit a php4-ben nem implementáltak, vagy az objektumjellemzők láthatóságának megoldása is hasznos dolog.
13

kukába vele ;)

Hodicska Gergely · 2007. Aug. 17. (P), 12.34
Egyébként sem akkora nagy ugrás a PHP5.
Hát pedig igencsak komoly előrelépés a PHP5 a négyhez képest, és nemcsak az OOP terén (bár valszeg a komoly felhasználás terén ez a leghangsúlyosabb). Kifejezőbb nyelvé vált, több nyelvi eszköz van a fejlesztő kezében (interfész, kivételek, statikus metódus, osztály szintű konstans), ráadásul biztonságosabb is lesz a kód, ugyanis bizonyos szükséges funkciókat (változók láthatósága, absztrakt osztály stb.) nem emulálva/dokumentálva tudsz biztosítani, hanem a nyel támogatja.

Aztán ott vannak az olyan témák, mint a SimpleXML, SOAP támogatás, PDO stb., ezek mint nagyon fontos újítások, amelyek által szintet ugrott a nyelv. Vagy pl. Reflection API is nagy jóság, lehetőséget nyújt az annotation használatára PHP-ban, ami szintén esetenként nagyon hasznos tud lenni. Szóval összeségében komoly változás a nyelv életében, lényegesen robosztusabbá vált.

Főleg ha figyelembe vesszük, hogy a PHP5 lassabban fut, mint az előző verzió.
Ez elég komoly tévhit. Az 5.0 valóban lassabb volt egy kicsit, de az 5.1-ben (lassan két éve kint van!) jelentős teljesítményt érintő változtatások voltak, melyek eredményeképpen, már általában gyorsabb volt a PHP4-hez képest, sok dologban lényegesen gyorsabb, és ez a tendencia folytatódott az 5.2-es verzióban is. Itt lehet róla bővebben olvasni. A változtatások között bőven akad olyan, ami nem csak az OOP fejlesztők számára lehet érdekes, hanem mindenkinek, például lokális változók elérésének hatékonyabbá tétele, átmeneti változók kezelése, garbage collector, default konstansok kezelése (TRUE, FALSE stb.), foreach kezelése, shutdown folyamat, include/require_once optimalizálása, átdolgozott memória kezelő (PHP4 -> PHP5.1: gyorsabb, de több memória, PHP5.1 -> PHP5.2: plusz memória foglalás megszüntetése).

A cikkben szerepel egy táblázat is különböző alap kódok sebességének összevetése különböző PHP verziók esetén. Elég alapvető dolgok, plusz különböző algoritmusok, egyetlen olyan érték nem volt, ahol a PHP4.4 gyorsabb lett volna, mint a PHP5.2.

Illetve volt még egy olyan konklúzió is, hogy pl. az átírt memória manager jótékony hatása csak nagy terhelés mellett mutatkozott, kis terhelés esetén nem volt jelentős hatása.


Üdv,
Felhő
15

A php4 nem eleve rossz

Balogh Tibor · 2007. Aug. 20. (H), 10.59
Ez lett volna a mondanivalója a hozzászólásomnak.
De nem akarnám tovább off-olni a témát. Azt senki nem vonta kétségbe, hogy oop terén nagy előrelépést tett a php5. A régebbi tesztek, amik 5.0 és 4.x hasonlították össze azt mutatták, hogy a 4 verzió gyorsabban fut. Az rendkívül örvendetes, hogy az 5.2 verzió nagy előrelépéseket tett teljesítmény terén. Így már csak a hoszt-cégektől függ, hogy milyen gyorsan merülhet feledésbe a php4.

Azért írtam, mert eleve a fönti kijelentésekből, hogy "kukába vele" meg hasonlók, majd egyesek fejében az születik meg, hogy php4 rossz php5 jó. Aminek annyi igazságtartalma van, mint annak, hogy "Négy láb jó, két láb rossz."
16

persze

Hodicska Gergely · 2007. Aug. 20. (H), 15.54
A php4 nem eleve rossz
Persze, ezt nem is mondanám én se, viszont mára már elavult, nem szól mellette semmi (leszámítva a szolgáltatókat, de pont erről szólna az említett kezdeményezés).

Egyébként sem akkora nagy ugrás a PHP5. Főleg ha figyelembe vesszük, hogy a PHP5 lassabban fut, mint az előző verzió.
Ez picit erősebb kijelentés azért.

Azért írtam, mert eleve a fönti kijelentésekből, hogy "kukába vele" meg hasonlók, majd egyesek fejében az születik meg, hogy php4 rossz php5 jó.
Ott volt egy smiley. ;) Viszont annyi igazságtartalma van, hogy ma már nem éri meg senkinek PHP4-gyel kezdeni, kár lenne egy eleve elavult valamit megtanulnia.[1]


Üdv,
Felhő

[1]: Persze a különbségeket érdemes lehet tudni, hogy ha az ember egy régebben írt rendszerrel találkozik, akkor ne csodálkozzon el.
17

ok

Balogh Tibor · 2007. Aug. 20. (H), 19.12
Akkor esetleg maradhatunk annyiban, hogy jelenleg érdemes olyan kódot írni, hogy működőképes legyen mindkét rendszerben. Kivéve persze, ha eleve php5 a követelmény.
18

szerintem nem

Hodicska Gergely · 2007. Aug. 21. (K), 01.16
Akkor esetleg maradhatunk annyiban, hogy jelenleg érdemes olyan kódot írni, hogy működőképes legyen mindkét rendszerben. Kivéve persze, ha eleve php5 a követelmény.
Én nem akarlak meggyőzni, úgy fejlesztesz, ahogy csak szeretnél, de az előző pár post részemről pont arról szólt, hogy a PHP5 egy lényegesen erőteljesebb eszköz egy programozó kezében, szerintem nem érdemes nem használni, ha csak nem komoly indok van az ellenkezőjére. PHP5 alatt meg PHP4 kompatibilis kódot írni nem sok értelme van (OOP alapokon).


Üdv,
Felhő
8

Megy szépen az 5-tel is most

Hodicska Gergely · 2007. Aug. 16. (Cs), 16.05
Per pillanat nincs vele gond 5.2-vel sem, leszámítva, hogy ki kell kapcsolni az Optimizert, ha szeretnél kivételeket elkapni. Már pedig azt szeret az ember. :)


Üdv,
Felhő
9

Régebben voltak hibák

Balogh Tibor · 2007. Aug. 17. (P), 09.31
ha szeretnél kivételeket elkapni. Már pedig azt szeret az ember.

Már ha használsz kivételeket, akkor igen. Ha nem, akkor szinte fel sem tűnik a hiányuk. :)
Egyébként Joel érdekes véleménye van a kivételekről. (Joel on Software, Joel a szoftverről)
14

link a konkrét cikkre?

Hodicska Gergely · 2007. Aug. 17. (P), 13.58
Tudsz postolni egy linket a konkrét írásra? (Google-ból nem derült ki egyértelműen, hogy melyikre gondolhattál.)


Köszi,
Felhő
19

felteszem erről volt szó

amonrpg · 2007. Aug. 21. (K), 07.46
http://www.joelonsoftware.com/items/2003/10/13.html