Discussion:
erdekes webserver lassulas
Honti Miki
2005-12-08 11:29:16 UTC
Permalink
sziasztok,


"sima" linuxon mar kerdeztem de ott nem jott meg otlet sem merre kene
elindulni. bocs, ha hosszu

az eredeti ket level:

elso:


sziasztok,

nem tudom mennyire offtopic, minden esetre erdekes jelenseget tapasztalok.

van egy webszerver, php, sql.

a lenyeg, hogy egy adott oldalon belul mindig ugyanott akad el az
oldal letoltese, var akar tobb masodpercet, aztan bejon a teljes
oldal. az igazan izgi, h semmi "extra" nincs a php kodban ott, ahol
elakad, se egy sql query, se uj file megnyitas, se semmi.

nem csak bongeszovel jon elo, wget-tel is ha kiiratom az stdoutra az
oldalt latszik hol akad el, ami raadasul mindig ugyanott van. tobb
fuggetlen internet eleresu geprol is ugyanez jon.

reszlet a kodbol:

print ...sokminden..."</select></td></tr></table></div></form>\n";
print "</div>\n";
print "<div id=\"top-right\">\n";


wget-tel nezve, amikor megall par entert utve:

...
</select></td></tr></table></div></form>

####itt all meg, jon a ket enter:

[ <=>
] 13,354
--.--K/s

[ <=>
] 13,354
--.--K/s </div>
<div id="top-right">
....


miert var vajon a </div> elkuldesevel? vagy mire var ha mar var?

barmilyen otletet szeretettel varok, nekem nemigen van :)

a rendszer egyebkent debian sarge, 2.6.8, apache2, php5.0, bar nem
hiszem h ez erdekes.

masodik level:

tovabb kiserleteztem, gondoltam az apache hibaja, beallitottam egy
lighttpd-t is masik portra, az mit csinal.

az is tok ugyanugy elakad, de kicsit leljebb az oldalon, nem 13354-nel
hanem 16034 -nal, latszolag ugyanugy nem "erdekes" kodnal.

mi lehet ez? fs, net?

koszi


levelek vege.


valahogy olyan erzesem van, hogy vmi eroforrasbol kap egy adott szeletet a
webserver, aztan amig nem kap megegyszer addig alldogal. mivel kulonbozo
webserverek mashol allnak meg, de egy adott mindig ugyanott, azt gyaniom
nem sql, php, vagy webserver okozza ezt, hanem valami 'leljebb' levo
eroforras, eth, fs, proci, vmi.

a proci csucsidoben persze ki van huzva maxra, gondolom leginkabb a
tobbszaz varakozo apache miatt.

nemi tovabbi info:
3g-s xeon proci, 320-as scsi swraid
egy oldalon sok (30-70) kep
xfs filerendszer

nemigen jon ki a dobozbol 5Mbitnel tobb forgalom, pedig szerintem igazan
johetne :)


koszi, udv

Miki
KORN Andras
2005-12-08 11:46:46 UTC
Permalink
Post by Honti Miki
nem csak bongeszovel jon elo, wget-tel is ha kiiratom az stdoutra az
oldalt latszik hol akad el, ami raadasul mindig ugyanott van. tobb
fuggetlen internet eleresu geprol is ugyanez jon.
print ...sokminden..."</select></td></tr></table></div></form>\n";
print "</div>\n";
print "<div id=\"top-right\">\n";
...
</select></td></tr></table></div></form>
[ <=>
] 13,354
--.--K/s
[ <=>
] 13,354
--.--K/s </div>
<div id="top-right">
....
miert var vajon a </div> elkuldesevel? vagy mire var ha mar var?
Esetleg probald meg strace-elni az apache-t (mondjuk indits egy masikat
80-astol eltero portszamon, es jatssz azzal).

Guy
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
When smashing monuments, always save the pedestals - they come in handy.
Honti Miki
2005-12-08 14:36:19 UTC
Permalink
Post by KORN Andras
Esetleg probald meg strace-elni az apache-t (mondjuk indits egy masikat
80-astol eltero portszamon, es jatssz azzal).
igaz ezt most eppen a lighttpd lett, de az ezt irja ki (megnezem az
apache-ot is mindjart)

writev(7, [{"HTTP/1.1 200 OK\r\nTransfer-Encodi"..., 377}, {"1ee9\r\n",
6}, {"<!DOCTYPE html PUBLIC \"-//W3C//D"..., 7913}, {"\r\n", 2}], 4) =
8298
setsockopt(7, SOL_TCP, TCP_CORK, [0], 4) = 0
epoll_ctl(4, EPOLL_CTL_MOD, 8, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=8,
u64=8}}) = 0
time(NULL) = 1134043041
epoll_wait(4, {{EPOLLIN, {u32=8, u64=8}}}, 1025, 1000) = 1
ioctl(8, FIONREAD, [8192]) = 0
read(8, "\1\6\0\1\37\370\0\000313\">:: Sanitation</opti"..., 8192) = 8192
brk(0) = 0x80ae000
brk(0x80d0000) = 0x80d0000
brk(0) = 0x80d0000
brk(0) = 0x80d0000
brk(0x80ce000) = 0x80ce000
brk(0) = 0x80ce000
setsockopt(7, SOL_TCP, TCP_CORK, [1], 4) = 0
writev(7, [{"1ff8\r\n", 6}, {"313\">:: Sanitation</option>\n<opt"...,
8184}, {"\r\n", 2}], 3) = 8192
brk(0) = 0x80ce000
brk(0) = 0x80ce000
brk(0x80cc000) = 0x80cc000
brk(0) = 0x80cc000
setsockopt(7, SOL_TCP, TCP_CORK, [0], 4) = 0
epoll_ctl(4, EPOLL_CTL_MOD, 8, {EPOLLIN|EPOLLERR|EPOLLHUP, {u32=8,
u64=8}}) = 0
time(NULL) = 1134043042
epoll_wait(4, {}, 1025, 1000) = 0
time(NULL) = 1134043043
epoll_wait(4, {}, 1025, 1000) = 0
time(NULL) = 1134043044
epoll_wait(4, {}, 1025, 1000) = 0
time(NULL) = 1134043045
epoll_wait(4, {}, 1025, 1000) = 0
time(NULL) = 1134043046
epoll_wait(4, {}, 1025, 1000) = 0
time(NULL) = 1134043047
epoll_wait(4, {}, 1025, 1000) = 0
time(NULL) = 1134043048
epoll_wait(4, {{EPOLLIN, {u32=8, u64=8}}}, 1025, 1000) = 1
ioctl(8, FIONREAD, [8192]) = 0
read(8, "\1\6\0\1\37\370\0\0n>\n<option value=\"30\">3"..., 8192) = 8192
setsockopt(7, SOL_TCP, TCP_CORK, [1], 4) = 0
writev(7, [{"1ff8\r\n", 6}, {"n>\n<option value=\"30\">30 per pa"...,
8184}, {"\r\n", 2}], 3) = 8192

a sok epoll_wait -nel varakozik, azt csinalja mindig, csak hat a gond h
azalatt nem csinal mast.

mit kene latom ebbol?
Honti Miki
2005-12-08 23:48:41 UTC
Permalink
Post by KORN Andras
Esetleg probald meg strace-elni az apache-t (mondjuk indits egy masikat
80-astol eltero portszamon, es jatssz azzal).
koszonom mindenkinek a segitseget, az apache strace-eles ugy tunik
meghozta az eredmenyt - nyilvan, a lighttpd fcgi-kent hivja meg a php-t,
igy ott nem lattam mi is tortenik.

ugy tnuik az sql query-k futottak le lassan, azokon kell faragni meg, de
az mar egy masik tema.

paraszti esszel azt gondoltam, h akkor a query kornyeken akad el
(tipikusan kozvetlenul utana), de nem...vagy hat ott akad el, de az
'kivulrol' nem latszik...na ertitek.

koszonom megegyszer, udv

Honti Miklos
Sickboy
2005-12-09 17:07:27 UTC
Permalink
Post by Honti Miki
ugy tnuik az sql query-k futottak le lassan, azokon kell faragni meg, de
az mar egy masik tema.
paraszti esszel azt gondoltam, h akkor a query kornyeken akad el
(tipikusan kozvetlenul utana), de nem...vagy hat ott akad el, de az
'kivulrol' nem latszik...na ertitek.
Amikor ilyesmit debugolsz, kapcsold ki a PHP-ben az output bufferinget.
--
.SiCk of IT.
Peter Bognar
2005-12-08 12:00:07 UTC
Permalink
Hali,

en kiprobalnam php4-el a helyedben. Elvileg nem lehet koze hozza, de
lattunk mar karon varnyut :)

s
Post by Honti Miki
sziasztok,
"sima" linuxon mar kerdeztem de ott nem jott meg otlet sem merre kene
elindulni. bocs, ha hosszu
sziasztok,
nem tudom mennyire offtopic, minden esetre erdekes jelenseget
tapasztalok.
van egy webszerver, php, sql.
a lenyeg, hogy egy adott oldalon belul mindig ugyanott akad el az
oldal letoltese, var akar tobb masodpercet, aztan bejon a teljes
oldal. az igazan izgi, h semmi "extra" nincs a php kodban ott, ahol
elakad, se egy sql query, se uj file megnyitas, se semmi.
nem csak bongeszovel jon elo, wget-tel is ha kiiratom az stdoutra az
oldalt latszik hol akad el, ami raadasul mindig ugyanott van. tobb
fuggetlen internet eleresu geprol is ugyanez jon.
print ...sokminden..."</select></td></tr></table></div></form>\n";
print "</div>\n";
print "<div id=\"top-right\">\n";
...
</select></td></tr></table></div></form>
[ <=>
] 13,354
--.--K/s
[ <=>
] 13,354
--.--K/s </div>
<div id="top-right">
....
miert var vajon a </div> elkuldesevel? vagy mire var ha mar var?
barmilyen otletet szeretettel varok, nekem nemigen van :)
a rendszer egyebkent debian sarge, 2.6.8, apache2, php5.0, bar nem
hiszem h ez erdekes.
tovabb kiserleteztem, gondoltam az apache hibaja, beallitottam egy
lighttpd-t is masik portra, az mit csinal.
az is tok ugyanugy elakad, de kicsit leljebb az oldalon, nem 13354-nel
hanem 16034 -nal, latszolag ugyanugy nem "erdekes" kodnal.
mi lehet ez? fs, net?
koszi
levelek vege.
valahogy olyan erzesem van, hogy vmi eroforrasbol kap egy adott szeletet a
webserver, aztan amig nem kap megegyszer addig alldogal. mivel
kulonbozo
webserverek mashol allnak meg, de egy adott mindig ugyanott, azt gyaniom
nem sql, php, vagy webserver okozza ezt, hanem valami 'leljebb' levo
eroforras, eth, fs, proci, vmi.
a proci csucsidoben persze ki van huzva maxra, gondolom leginkabb a
tobbszaz varakozo apache miatt.
3g-s xeon proci, 320-as scsi swraid
egy oldalon sok (30-70) kep
xfs filerendszer
nemigen jon ki a dobozbol 5Mbitnel tobb forgalom, pedig szerintem igazan
johetne :)
koszi, udv
Miki
_______________________________________________
linux++ mailing list
http://mlf2.linux.rulez.org/mailman/listinfo/linux++
Sickboy
2005-12-08 12:48:03 UTC
Permalink
Post by Honti Miki
a lenyeg, hogy egy adott oldalon belul mindig ugyanott akad el az
oldal letoltese, var akar tobb masodpercet, aztan bejon a teljes
oldal.
print ...sokminden..."</select></td></tr></table></div></form>\n";
print "</div>\n";
print "<div id=\"top-right\">\n";
...
</select></td></tr></table></div></form>
####itt all meg
Ez szerintem eleg rossz megkozelites, hogy a "vegponton" nezve mikor jon
meg valami. Meg kene nezni, hogy a php interpreter mit lat. En tennek a
kodba helyenkent eleg pontos (tehat masodpercnel nagyobb felbontasu
magyarul microtime()) timestampes loggolast ("ittvan1","ittvan2",stb ;)

A tippem egyebkent meg az is, hogy output buffering?
Ugyanis ettol ha a script egy kesobbi ponton elakad, de meg nem
flush-olta a buffert, akkor a vegponton nezve olyan, mintha a "semmi
erdekes" kozepen allt volna meg, pedig nem.
--
.SiCk of IT.
Pallai Roland
2005-12-08 17:03:10 UTC
Permalink
Post by Sickboy
Post by Honti Miki
####itt all meg
Ez szerintem eleg rossz megkozelites, hogy a "vegponton" nezve mikor jon
meg valami. Meg kene nezni, hogy a php interpreter mit lat. En tennek a
kodba helyenkent eleg pontos (tehat masodpercnel nagyobb felbontasu
magyarul microtime()) timestampes loggolast ("ittvan1","ittvan2",stb ;)
A tippem egyebkent meg az is, hogy output buffering?
Ugyanis ettol ha a script egy kesobbi ponton elakad, de meg nem
flush-olta a buffert, akkor a vegponton nezve olyan, mintha a "semmi
erdekes" kozepen allt volna meg, pedig nem.
pontosan, alapban termeszetesen van output buffering a php-n, tehat a
kod mar reg tul lehet azon ahol a kiiras all. ha a microtime() hegyek
sem mutatnak semmit akkor meg van 1 lehetoseg, hogy sok memoriat foglal
a script es miutan lefutott ennek a felszabaditasaval meg hosszu
masodperceket elbohockodik a php. ez a kodbol nem merheto, viszont
hasonlo jelenseg, elakad a kiiras nagyjabol azonos helyen. erre
workaround lehet ra vagy 2000 bajt whitespace a </html> moge es persze
az esszeru memoriahasznalat..
--
dap
Sickboy
2005-12-08 18:39:24 UTC
Permalink
Post by Pallai Roland
meg van 1 lehetoseg, hogy sok memoriat foglal
a script es miutan lefutott ennek a felszabaditasaval meg hosszu
masodperceket elbohockodik a php. ez a kodbol nem merheto, viszont
hasonlo jelenseg, elakad a kiiras nagyjabol azonos helyen. erre
workaround lehet ra vagy 2000 bajt whitespace a </html> moge es persze
az esszeru memoriahasznalat..
Na erre kivancsi vagyok. Nagysagrendileg mekkora memoria hasznalat
eseten tapasztalhato ez a masodpercekben merheto lassulas?
Mert en meg ilyet nem lattam.
--
.SiCk of IT.
Pallai Roland
2005-12-08 22:54:47 UTC
Permalink
Post by Sickboy
Post by Pallai Roland
meg van 1 lehetoseg, hogy sok memoriat foglal
a script es miutan lefutott ennek a felszabaditasaval meg hosszu
masodperceket elbohockodik a php. ez a kodbol nem merheto, viszont
hasonlo jelenseg, elakad a kiiras nagyjabol azonos helyen. erre
workaround lehet ra vagy 2000 bajt whitespace a </html> moge es persze
az esszeru memoriahasznalat..
Na erre kivancsi vagyok. Nagysagrendileg mekkora memoria hasznalat
eseten tapasztalhato ez a masodpercekben merheto lassulas?
Mert en meg ilyet nem lattam.
emlekeim szerint egy ilyesmi struktura fogta meg rendesen:

$matrix[1 .. 2000][1 .. 30] = stringek 5-60 karakterbol

ami kb 6.000.000 elem es 48M -re kellett emelni a mem limitet hozza. a
felepitese gyorsabb volt mint a legvegen a felszabaditas, az olyan 2-3mp
volt.. es persze a browser vegigvarta amig nem tettem egy flush -t a
kod vegere vagy egy rakat ertelmetlen space-t.. azota sql-re biztam a
dolgot


--
dap
Loading...