Oldal betöltési probléma (Sever Error, premature end of script header: index.php)
Sziasztok!
már egy ideje küzködöm egy problémával, a segítségeteket szeretném kérni. Van egy php ban írt oldalam, amelyiknél bizonyos körülmények között van egy olyan hibajelenség, hogy 30mp -ig homokórázik, aztán ad egy hibaüzenetet: Sever Error, premature end of script header: index.php
- a php.ini ben a "max_execution_time" 180sec -re van állítva, ellenőriztem phpinfo()-val, illetve le is teszteltem, ez szerintem rendben.
- a hiba okát is felderítettem. Az oldal akkor töltődik be lassan, ha előtte az admin felületen pl. 10-15 db képet feltöltök. A php motor ilyenkor az imagemagick "convert" programjának segítségével átméretezi a képeket optimális méretre, majd azokat elmenti a saját cache tárba. A szerveremen ez a folyamat lassú, és ez sajnos több időbe telik, mint 30 mp. Az oldal viszont 30mp után újratölti magát, és annak okán, hogy a cacheba még nincsenek benne azok a képek, amiknek benne kell lennie, hibára fut.
- a hiba egy typo3 cms-el készült oldalon jelentkezik. Typo3-al foglalkozó levelezőlistákon már többször is jeleztem a problémát, valamiért nem foglalkoznak a problémajelzésemmel. (Ezek szerint az ő kódjuk teljesen rendben van, a hiba nálam van...)
- A "premature end osf script header" hibaüzenetnek is utánaolvastam: pl. http://httpd.apache.org/docs/1.3/misc/FAQ-F.html#premature-script-headers - sajnos itt már elvesztettem a fonalat.
Kérem segítsen valaki a problémát megoldani (akár magánba is - a részleteket megbeszéljük)- tömören azt szeretném, hogy ha a képek legenerálása tovább tart mint 30 sec, akkor homokórázzon tovább, és ne dobja ezt a hibaüzenetet.
Köszönöm előre is
■ már egy ideje küzködöm egy problémával, a segítségeteket szeretném kérni. Van egy php ban írt oldalam, amelyiknél bizonyos körülmények között van egy olyan hibajelenség, hogy 30mp -ig homokórázik, aztán ad egy hibaüzenetet: Sever Error, premature end of script header: index.php
- a php.ini ben a "max_execution_time" 180sec -re van állítva, ellenőriztem phpinfo()-val, illetve le is teszteltem, ez szerintem rendben.
- a hiba okát is felderítettem. Az oldal akkor töltődik be lassan, ha előtte az admin felületen pl. 10-15 db képet feltöltök. A php motor ilyenkor az imagemagick "convert" programjának segítségével átméretezi a képeket optimális méretre, majd azokat elmenti a saját cache tárba. A szerveremen ez a folyamat lassú, és ez sajnos több időbe telik, mint 30 mp. Az oldal viszont 30mp után újratölti magát, és annak okán, hogy a cacheba még nincsenek benne azok a képek, amiknek benne kell lennie, hibára fut.
- a hiba egy typo3 cms-el készült oldalon jelentkezik. Typo3-al foglalkozó levelezőlistákon már többször is jeleztem a problémát, valamiért nem foglalkoznak a problémajelzésemmel. (Ezek szerint az ő kódjuk teljesen rendben van, a hiba nálam van...)
- A "premature end osf script header" hibaüzenetnek is utánaolvastam: pl. http://httpd.apache.org/docs/1.3/misc/FAQ-F.html#premature-script-headers - sajnos itt már elvesztettem a fonalat.
Kérem segítsen valaki a problémát megoldani (akár magánba is - a részleteket megbeszéljük)- tömören azt szeretném, hogy ha a képek legenerálása tovább tart mint 30 sec, akkor homokórázzon tovább, és ne dobja ezt a hibaüzenetet.
Köszönöm előre is
Aszinkron feldolgozas.
Nyilvan, amig egy kep nincs feldolgozva az eles oldalon nem jelenik meg, vagy valami default kepet raksz ki helyette.
Hibás a typo3 core...?
Az aszinkron feldolgozás jó ötlet. Belenézek azért a typo3 core kódjába, és megpróbálom megnézni, hogy mi az akadálya, hogy ha a képfeldolgozás nem fut le, akkor a homokórázás helyett valami default kép jelenjen meg...de eddigi ismereteim szerint a typo3 úgy működik, hogy egy oldal betöltése mindig cache-n keresztül történik, a cachelt tartalom pedig mindig az oldal első betöltésekor generálódik le, nem pedig azután, hogy az admin felületen felvittem adatokat.
Szóval nemtudom mit kéne tenni - az általatok javasolt megoldásokat elég nehéz lenne beleültetni a typo3 kódjába.
max_exec
Miért nem próbálod a typo-t kiszedni a rendszerből. Pár kép konvertálása nem olyan iszonyatosan bonyolult művelet, hogy kész kódtra lenne szükséged... Így redukálnád a hibalehetőségeket is...
A másik dolog, meg ha ajánlatok egy alternatyv kép-méretező megoldást:
http://vbence.web.elte.hu/php_kep_meretezes_vizjel.html
talán csak egy apró konfigurációs probléma?
safe mode van, de a pl. phpmyadminnál amikor nagyméretű adatbázis exportálok ki, akkor tapasztalom, hogy egy php scrupt futhat 30mp nél több ideig is. Tehát megnövelt a max_execution_time beállítást a php figyelembe veszi, mégis 30mp múlva jön ez a premature end of script header hiba.
A typo3-at azért nem szeretném kiszedni, mert a weboldalam teljes egészében ezt a keretrendszert használja, nem csak a képátméretezést csinálja. De a képátméretezést nem is a typo3, hanem egy külső program "convert" végzi, ez az imagemagick nevű program része. Sőt ez külön processzként is fut, látom is a processzek között ha a konczolon "ps" parancsot kiadom.
Egyébént bocsánat a témafelvetésért, bizonyos szempontból teljesen offtopik, typo3 téma. De esetleg tudnátok e javaslatokat adni, hogy miként tudnék jobban a mélyére nézni a hibának - szerintem az már elegendő lenne, ha a typo3 fejlesztőknek többet is tudnék modnani a hibáról, mint amit itt leírtam. A "premature end of script header" az túl kevés, egyik fejlesztő ezt egyszer már megírta.
typo3
A támaindítót újraolvasva viszont azt hiszem jobban megértettem a dologt. Ellenőrzás képpen: az admin felület éppen dolgozza fel aképeket, eközben az éles oldal adja ezt a hibát? Ha igen, milyen módon akarja elérni a cache-elt képeket az éles oldal? Csak a nevüket írja a forrásba (azaz nincs fájművelet), vagy - nagyon helytelenül - megnyitogatja az összes képet, és pl a méretüket is beleírja a keletkező html forrásba?
Ha a második, akkor extrém esetben előfordulhat, hogy a konvertáló létrehozza a fájlt, de lock alatt tartja amég ír bele, ezt a lockolt fájlt próbálja az éles oldal beolvasni, ami nem megy neki, viszont nem próbálja újra, hanem egyszerűen valahol timeoutos lesz. - Ez persze egy elég merész, légbőlkapott elmélet...
Milyen módon fut a php (mod_php vagy fastcgi)?
typo3 működése
Az éles oldal (frontend - FE) pedig attól függően, hogy mit adsz meg paraméterként a index.php?id= , kiolvassa az adatbázisból az ottani tartalmat, és megjeleníti. De előtte az egész átmegy egy cachelésen. Így az oldal első alkalommali betöltése lassú, minden további esetben ez gyors.
A cachelési folyamatnál a typo3 core valamilyen úton módon meghívja a convert progit, a progi útját egyébként a typo3 installációkor én adom meg, de a van, hogy a typo3 maga megtalálja. Szóval mihelyt megnyitom az éles oldalt, a consolon rögön látom, hogy a convert progi átméretezi a képet. pl. egy 8 Mpixeles képet bélyegkép méretűre. Ez akárhogy is nézzük, időigényes folyamat. Ha sikeresen lefut, akkor a bélyegkép bekerül a typo3temp könyvtárba, az éles oldalon pedig a kép útja is ez lesz.
A probléma egyébként dinamikus oldalkezeléskor jön elő. Van egy news hírkezelő modul, aminek egy lista nézetét beteszek az egyik oldalra, a teljes nézetét pedig egy másik oldalra, illetve egy tároló oldalra felviszem a rekordokat, amelyekben a szöveg és a kép van. Illetve azt is meg tudom csinálni, hogy a főlapra kiteszek egy legfrisebb nézetet, akkor ha egy új rekordot fűzök a hírtárolóba, majd amihez kapcsolódik mondjuk 4-5 kép is, akkor az megjelenik a főoldalon. Persze a cachelés miatt ilyenkor a főoldal nem jelenik meg azonnal, kell várni néhány mp-et.
A dolog akkor bukik ki (sajnos), ha sok az új kép. pl. 10-15 db. Ilyenkor az admin felületen feltöltöm, aztán megnézem a főoldalt, és puff jön a hiba.
összességében a működésben lehet hibát keresni, szerintem nem ez kell hogy vezessen a megoldásra. Felépítésében nagyon jól átgondolt rendszernek tapasztalom - a legnagyobb hátránya az, hogy kicsit "pilótavizsgás"
fastcgi-ben fut az apache.
Talán...
A másik dolog, hogy kényelmes és klassz dolog, hogy csak feldobálod a kameráról a képeket a szerverre, de mint látható erre nem igazán érett még meg a vlág :) Mi lenne, ha kliensoldalon csinálnál minden képből egy 800x800-as verziót, és a többi változatot már csak ebből kell elkészíteni (ami lényegesen erőforráskímálőbb). A neten általában amúgy sincs szükség nagyobb felbontásra.
képgenerálás
Amit a másik dologgal írsz: Ezt nyilván nekem el tudod magyarázni, és még igazat is adok neked. Eleve tudom, hogy ha takarékosokdni szeretnék a hellyel, akkor előtte nem árt átméretezem a képeket pl. 800*600-ra, abból a bélyegképgyártás is mindjárt gyorsabb. Illetve a képeket sem huszasával töltöm fel, illetve minden adag után megnyitom a FE-n azt az oldalt, ami a képgenerálási folyamat elindítását jelenti. De ügyfélnek mindezt azthiszem már körülményes lenne elmagyarázni. (Vagy csak mi vagyun bénák?)
Szerintem ezt valahol lehet lustában is csinálni. Talán azt kéne meglelni, hogy ez a 30sec honnan a fenéből jön? Kerestem grep-el, de semmi.
Előfeldolgozás kézzel?
(Fast)CGI
Sajnos erre csak egy rossz hírem van, vagy átállítod az apache-ot, hogy több madzagot engedjen a Typo3-nak, vagy, és ezt javaslom, átírod az alkalmazásod úgy, hogy tisztességes módon dolgozza fel a képeket valami feldolgozási sorban.
fastcgi config?
#!/bin/sh
PHPRC="/var/www/vhosts/domain/bin"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
az apache.conf-ból pedig ez a releváns rész szerintem.
AddHandler fcgid-script .php
SuexecUserGroup alvator psacln
<Directory /var/www/vhosts/domain/httpdocs>
FCGIWrapper /var/www/vhosts/domain/bin/php5-fcgi-starter .php
Options FollowSymLinks ExecCGI
allow from all
</Directory>
szerinted ez nem elég? PHP_FCGI_CHILDREN=4
a rendszer debian etch, az debian által csomagolt apache2-mpm-prefork csomag fut, a prefork configja pedig
<IfModule prefork.c>
StartServers 1
MinSpareServers 1
MaxSpareServers 2
MaxClients 35
MaxRequestsPerChild 1000
</IfModule>
Ezeket úgy innen onnan lőttem...
Ismerős...
Az eredeti problémán sajnos nem változtat, méghozzá hogy ezt queue-ban kellene csinálni, nem realtime. :)
Megoldottad :) Köszönöm.
<IfModule mod_fcgid.c>
AddHandler fcgid-script .fcgi
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 20
</IfModule>
Az IPCConnectTimeout 20 at megnöveltem 180-ra.
feltöltöttem 80 képet, és kb. 40sec alatt végzett vele :)
Mindenkinek köszönöm a segítséget, tippeket, ötletelgetéseket.
Great :)
Arra érdemes figyelni, hogy a mods-available/enabled tartalma upgradekor fölülíródhat, lehet hogy érdemesebb lenne a conf.d könyvtárban valamelyik fájlba beletenni. Nem tudom, melyik config fájl opciója írja fölül melyiket, de ez kisérletezés kérdése.
megkerülés helyett megoldás
valami azért furcsa volt nekem. phpinfoval megnéztem hogy az milyen modulokat mutat, mik azoknak a paraméterei. Ott azok között én nem láttam ezt az IPCConnectTimeout -ot. Használja e egyáltalán a rendszer? Egyértelműen akkor láttam, hogy a /var/lib/apache2/fcgid/sock -n belül ott csücsülnek a socketek.
Köszi a figyelmeztetést az upgrade esetére. Persze azért itt is célszerű odafigyelni, hogy ha egyedi beállításokat beírom oda ahova mondjuk a netes doksik mondják, akkor kedves apache nem vicceli e meg az embert azzal, hogy amikor összeincludolja a szanaszét heverő httpd.conf egyes részeit, akkor előszőr jön a te konfigurációd, aztán ami a mods-available/enabled -ben van?
A typo3 belső működése meg hogy jó e így vagy nem, azt majd eldöntik a fejlesztők - szerintem ha az esetleges korábbi átgondolatlanságokból eredő problémákat lehet hasonló módon orvosolni, mint ahogy segítségednek köszönhetően megtettem, akkor lehet hogy nem érdemes azzal a résszel foglalkozni.
Upgrade
Ami a Typo3-at illeti, kérdés hogy az a kevesebb energia, hogy a szervert hozzáhajlítod az ő követelményeikhez/kényelmességükhöz/ne adj Isten, nem tudásukhoz, vagy az a kevesebb energia, hogy egy picit átgondolják, hogy kívánják a tartalmaikat publikálni. Ha a Typo3 nem elég flexibilis ahhoz, hogy ezt tudja, akkor lehet, hogy nagyobb mennyiségű képnél egyszerűen már nem tudod elég magasra tekerni a szervert, úgyhogy az eszköz nem felel meg a céljaitoknak... ezek ilyen kósza gondolatok, amik fölmerülnek a fejlesztéssel kapcsolatban, hogy mi felel meg belőlük a Ti helyzeteteknek, azt Neked kell eldöntened. :)
de ha fastcgi hibaüzenet, akkor honnan jön a 30sec?
A fastcgi honnan tudja, hogy mikor jár le neki a feldolgozás? Ha a hibaüzenet a max_execution time lejártakor jönne, akkor érteném..
PHP <-> FastCGI
plesk rendesen bekavar
FastCGI
Hogy csak egy példát mondjak, nem mindegy, a suexec-et milyen paraméterekkel forgatod le, nem mindegy mi hol van, nem mindegy, hányas Apache fut, stb. És akkor még a PHP-s, adott esetben elcseszett alkalmazásokról nem is beszéltünk.
A legtriviálisabb probléma egyébként legtöbbször az, hogy az adott disztró gyártói meghoznak döntéseket és ezek nem egyeznek meg a cikkíró által használt disztribúció / verzió paramétereivel. :)
A Linuxra sajnos az igaz, hogy sokat, végtelenül sokat kell tanulni és még többet kell tapasztalni ahhoz, hogy meg tudd oldani a felmerülő problémákat. Ugyanúgy, ahogy Te, én is elolvastam a Weblaboros cikket annó és ugyanúgy szívtam - végigszívtam a saját szerveremmel a FastCGI berendezését. És nem kevés idő volt. Ezzel összemérhető időmennyiséget csak a levelezés beállítása emésztett fel.
Ha a téma címéből következtetek, Te valami kész admin-panelt szerettél volna használni a gépeddel. Sajnos el kell szomorítsalak, ezek az admin panelek akkor és csak akkor működnek, ha pontosan úgy rakod föl az egész gépedet, ahogy ők azt megálmodták. Ha arra vágysz, hogy ne kelljen ismerni, ne kelljen foglalkozni vele, akkor ez nem az a fajta szoftver, mert túl sok egyszerűen a faktor ahhoz hogy ez így tudjon menni.
Plesk
Linuxban egyébként sok éves tapasztalatom van, és eddig nálam is a levelezés és a fastcgi-be kellett a legtöbb energiát belefektetnem. Működik, de eddig még lenne mit rajtuk finomítani. De látom, hogy újra elő kell venni a doksikat, és át kell nyálazni az összeset teljes mélységében, átgondolni, majd aszerint rendesen bekonfigurálni a szerveremet.
A Pleskben pont az a lényeg, hogy a rendszer úgy van összeállítva, ahogy a plesk-et készítő cég megálmodta, cserébe szerintem a szervered is úgy fog működni, ahogy azt ők megálmodták. :) Ha módosítani szeretnél valamit, akkor ott érdemes követni a plesk útmutatásait, amelyek jóval szigorúbbak, mint ahogy a csomag leírásában található leírás említi. pl. rendszergazdaként a httpd.conf-ot te ott módosíthatod ahol akarod, a plesk-es rendszernél a fájloknál oda van írva, hogy "ne módosítsd", az egyedi konfigurációknak meg van a maguk helye.
Plesk
Ami a Plesket illeti, próbálgattam már jópár admin felületet, de egyik sem nyerte el a tetszésemet annyira, hogy meg is tartsam. Az igazat megvallva, ezek a rendszerek tömegeket szolgálnak ki, az én igényeim pedig elég speciálisak szoktak lenni (a szerveremen pl minden domainhez saját error/access log, spam statisztika, stb.) szóval inkább saját utakat járok. Most próbálok éppen összerakni egy alapvető rendszert a webes adminisztrációra, ami képes az alapvető dolgokat ellátni.