|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
|
|
weblap lassulásSziasztok!
Gondoltam feldobom egy kicsit a listát, s ismét egy kissé talán túl általános kérdést tennék fel... Van egy webshop, ami néha "belassul". Ez alatt azt kell érteni, hogy egy nap kb 80% -ban nincs vele semmi gond kb 0,2-0,5 sec alatt betölti az oldalt, de a maradék időben nagyon megnő az oldalbetöltési idő (akár 60 sec is lehet!!!). Nem látogatják olyan sokan az oldalt, napi 250 - 300 látogató van. (Oldalbetöltési idő alatt a php script futási idejét értem.) Még nem volt sok "lehetőségem" az ilyen dolgok kidebuggolására, hogy mi lehet rossz a kódban, így a ti segítségeteket szeretném kérni. Nagy valószínűséggel ugyanis tényleg a kódban van a bibi, ugyanis már két másik szerveren is futtattuk a dolgot, és mindkettőnél tapasztalható volt, pedig ott csak 2 -en teszteltük, tehát más nem is látogathatta. Sajnos kicsit sok az sql kérés, de ezt már igyekeztem drasztikusan csökkenteni. De most ott tartunk, hogy valószínűleg nem is az sql -ek darabszámával lehet a baj. Kérdésem a tapasztaltabbakhoz, hogy milyen adatokat nézzek, teszteljek, egyáltalán milyen tippek vannak, mert mint mondtam nekem még nem volt hasonló hibával dolgom, így nincs is tapasztalatom benne. Minden segítséget előre is köszönök! Zogmund -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: weblap lassulásSzerintem azert csak nezd meg az SQL-t. Lehet, hogy valahol valami
lockol egy darabig. Ezen kivul lehet timeout kivaras kulso eroforras (halozati kapcsolat, remote fajl, stb.) eleresekor. Erdemes a gyanus programreszben idomero pontokat felvenni, hogy kideruljon, hogy merrefele van a hiba. Meg egy otlet: session. A session_start tud varakozni eleg sokaig, ha nem sikerul megnyitni a session fajlt. Ez akkor fordulhat elo, ha parhuzamosan tobb szalon jon ugyanaz a user (frame, ek, ajax, stb.) Udv: Csongi bacsi Ambrus Zoltán írta: > Sziasztok! > > Gondoltam feldobom egy kicsit a listát, s ismét egy kissé talán túl > általános kérdést tennék fel... > > Van egy webshop, ami néha "belassul". Ez alatt azt kell érteni, hogy egy > nap kb 80% -ban nincs vele semmi gond kb 0,2-0,5 sec alatt betölti az > oldalt, de a maradék időben nagyon megnő az oldalbetöltési idő (akár 60 > sec is lehet!!!). Nem látogatják olyan sokan az oldalt, napi 250 - 300 > látogató van. (Oldalbetöltési idő alatt a php script futási idejét értem.) > Még nem volt sok "lehetőségem" az ilyen dolgok kidebuggolására, hogy mi > lehet rossz a kódban, így a ti segítségeteket szeretném kérni. Nagy > valószínűséggel ugyanis tényleg a kódban van a bibi, ugyanis már két > másik szerveren is futtattuk a dolgot, és mindkettőnél tapasztalható > volt, pedig ott csak 2 -en teszteltük, tehát más nem is látogathatta. > Sajnos kicsit sok az sql kérés, de ezt már igyekeztem drasztikusan > csökkenteni. De most ott tartunk, hogy valószínűleg nem is az sql -ek > darabszámával lehet a baj. > > Kérdésem a tapasztaltabbakhoz, hogy milyen adatokat nézzek, teszteljek, > egyáltalán milyen tippek vannak, mert mint mondtam nekem még nem volt > hasonló hibával dolgom, így nincs is tapasztalatom benne. > > Minden segítséget előre is köszönök! > > Zogmund > Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: weblap lassulásFirefox+Firebug => megláthatod az összes kérést, ami a szerverhez megy,
fejléccel, idővel. Ha php kérés, akkor session=> amíg az egyik nem fut le, addig a másik vár. Képek, css nem számít, de ajaxos hívás igen, amikor a szerver oldalon php szolgálja ki a kérést. Ezt úgy tudod gyorsítani, hogy mihelyt lehetséges lezárod a sessiont session_write_close()-zal, és utána állítja elő a kód a tényleges oldalt. SQL kérések számának csökkentése. Ha nem túlságosan változik az oldal, akkor az SQL eredmények cache-elése. Ne használj olyan lekérdezést, amelynek sok sorból áll az eredménye, azaz lapozást használj. memcache-használata, az még a session-t is képes tárolni memóriában!, ha a szolgáltató engedi Egyéb php cache megoldások, mint például smarty Minél kevesebb kódot állíts össze php-val, azaz válaszd szét az alkalmazás logikát és a felületet. A kódodban, ahogyan korábban is mondták helyezz el időmérési pontokat és azt irasd ki. Használj olyan IDE-t, amellyel tudsz Profile-t készíteni (pl. Zend IDE), atz megmondja, hogy melyik modulban meddig tevékenykedett a kódod. További általam ismert módok: http://www.fzolee.hu/framework/wamp_sebessegoptimalizalas Fabio -----Original Message----- From: wl-phplista-bounces@... [mailto:wl-phplista-bounces@...] On Behalf Of Halmai Csongor Sent: Wednesday, October 21, 2009 5:28 PM To: weblabor PHP levlista Subject: Re: [wl-phplista] weblap lassulás Szerintem azert csak nezd meg az SQL-t. Lehet, hogy valahol valami lockol egy darabig. Ezen kivul lehet timeout kivaras kulso eroforras (halozati kapcsolat, remote fajl, stb.) eleresekor. Erdemes a gyanus programreszben idomero pontokat felvenni, hogy kideruljon, hogy merrefele van a hiba. Meg egy otlet: session. A session_start tud varakozni eleg sokaig, ha nem sikerul megnyitni a session fajlt. Ez akkor fordulhat elo, ha parhuzamosan tobb szalon jon ugyanaz a user (frame, ek, ajax, stb.) Udv: Csongi bacsi -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
Re: weblap lassuláshali!
> lockol egy darabig. Ezen kivul lehet timeout kivaras kulso eroforras > (halozati kapcsolat, remote fajl, stb.) eleresekor. Erdemes a gyanus > programreszben idomero pontokat felvenni, hogy kideruljon, hogy > merrefele van a hiba. ... tovabba lehet, hogy valamifele dns feloldasi problema is befigyelhet, ha van ilyen pont az alkalmazasban (pl. kulso url). Esetleg "veletlen" http-rol valo include? A halozati kapcsolatok szempontjabol erdemes egy netstat-ot is figyelni, ha esetleg tcp szinten lenne a problema, valamint az sql szerver connection limitjet is erdemes megnezni, ha esetleg nagyon felszaporodna a keres, az meg alacsonyra van allitva (esetleg ugyanez a webszerverre nezve is). > Meg egy otlet: session. A session_start tud varakozni eleg sokaig, ha > nem sikerul megnyitni a session fajlt. Ez akkor fordulhat elo, ha ... vagy ha pl. elfogy a /dev/random "tartalma", es kicsi varni kell, mire jon valahonnan bele adat (ezt eleg egyszeru ellenorizni, latod, hogy elakad-e). Egyebkent http-n es https-en is elofordul a hiba? Valamint ezzel a cuccal is meg lehet meg fogni a dolgot, ha belathato idon belul eloidezheto a problema, es az tenyleg a PHP-ben van: http://www.php.net/manual/en/apd.examples.usage.php Udv, JoE -- Weblabor hírlevél: http://weblabor.hu/hirlevel -- wl-phplista (wl-phplista@...) levelezőlista https://bors.hoszting.com/mailman/listinfo/wl-phplista Keresheto archivum: http://weblabor.hu/kereses -- etikett: http://weblabor.hu/levlistak/illemszabaly offlista: https://weblabor.hu/levlistak |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |