ugrás a tartalomhoz

Érdekes kiszolgálói jelenség

s_volenszki · 2009. Feb. 10. (K), 22.02
Tapasztaltam mostanság egy érdekes jelenséget, kutatom az okát, de egyenlőre még nem sok mindent találtam. Kérlek titeket osszátok meg velem, ha van tapasztalatok, ötletetek a témában!

Apache webszerveren viszonylag sokszor, úgy 10 oldalbetöltődésből egyszer, bekövetkezik egy gyakran 5-10 másodperces letöltődési idő. A jelenség úgy néz ki, hogy a kattintás után a böngésző nem csinál semmit vagy 4-8 másodpercig, majd megindul és kb. 1 másodperc alatt betölti az oldalt.

Tettem egy mérő kódot a front controller-be és kiegészítettem a log táblát egy amolyan oldalgenerálási idő mezővel. Indítottam egy Wiresharkot meg egy YSlow-t és elkezdtem egymás után ugyanarra a hivatkozásra kattintani.

Katt, várok míg az oldal letöltődik, aztán ugyan oda megint katt és megint várok...

Egy átlagos letöltődés kb.: 0.3-0.9 másodperc és az ehhez tartozó oldal generálásához szükséges idő: 0.005 - 0.3 másodperc között mozog.

Amikor a 10 letöltődésből egyszer előfordul a "beragadás", akkor a következő adataim vannak:

letöltődés kb.: 4.4-8.9 másodperc és az ehhez tartozó oldal generálásához szükséges idő változatlanul: 0.005 - 0.3 másodperc között mozog.

A következőket próbáltam még, ami elég érdekes eredményt hozott.

Készítettem egy sima html fájlt, értelem szerűen, most már csak a Wireshark-ra és a YSlow-ra támaszkodva. Adatok:

Letöltődés: 0.03-0.08 másodperc között "beragadás" nélkül.

Ezek után készítettem egy műveletek nélküli php fájlt és láss csodát! Kb a 6. letöltődésre produkált egy 5.93 másodperces időt!

Mi lehet itt a bibi?
 
1

Server-status

janoszen · 2009. Feb. 10. (K), 22.47
Egyrészt nézd server-statust, másrészt az ilyenkor szokásos rendszet-dolgokat: top, iostat, ifstat, syslog, mytop, illetve ezek alternatíváit a Te rendszereden. Próbáld mef kikapcsolni a keep-alive-ot, megnövelni az Apache szálak számát, nézd meg a párhuzamos szálakat, ajax requesteket a megfelelő eszközökkel. Kapcsopd ki a PHP debuggereidet. Olvasd el a HTTP RFCt, guglizz. Ezek jutottak hirtelen eszembe.
2

Nem teljesen értelek, de lehet, hogy nem voltam egyértelmű.

s_volenszki · 2009. Feb. 10. (K), 23.54
Egyszerű végfelhasználó vagyok aki, fogást keres a hibajelenségen, hogy segítséget kérhessek a szerver üzemeltetőjétől.

Elég gyenge lábakon áll egy olyan hibajelenség magyarázata, hogy 10 letöltődésből átlagosan egy, közel tíz másodpercig tart.

Gondoltam, körülnézek a saját házam táján, mielőtt farkast kiáltok.

Átnézem, hogy amiket javasoltál, azok közül mivel bírok átlag user jogokkal parancssor nélkül...

s_volenszki
5

Apache szálak

janoszen · 2009. Feb. 11. (Sze), 10.47
Tfh az Apache 300 szállal fut max és 30 másodperces keep alive értékkel. Ez esetben ha összegyűlik 300 nyitott kapcsolat ezen időn belül, akkor Neked a 301-kel várnod kell, amíg valakinek a 300-ból le nem telik a 30 másodperc.

Ezen felül még lehet persze millió oka, pl egy hibás SATA kábel is, amitől néha leesik a disk a portról, de ez a legvalószínűbb.
3

Cron

Poetro · 2009. Feb. 11. (Sze), 01.13
Nem lehet, hogy sikerül beletrafálni valami cron futasba, vagy egy DB LOCK-ba, ezért tart időnként a generálás tovább?
Vagy próbáld egy SSH sessionből, egy viszonylag gyors hozzáférésű mondjuk szerver gépen wget-tel, hogy kizárjuk, hogy a te géped / netkapcsolatod a ludas.
4

Lehetséges okok.

s_volenszki · 2009. Feb. 11. (Sze), 09.34
A tesztelés során, amikor már nem mérem php-vel, hogy mennyi idő alatt generálódik az oldal, csak Wireshark-ot és YSlow-t használtam, akkor ezt a php fájlt futtatom:

<?php
?>
Ebben az esetben mi befolyásolhatja a futási időt? Azt a szolgáltatásról tudom, hogy egy időben csak 5 php fájl futhat, azonban a statisztika szerint egyedül vagyok a szerveren, mikor a jelenség bekövetkezik, és a kérés csak egy php fájlból áll adatbázis művelet és munkamenet kezelés nélkül.

Egyébként megpróbáltam másik gépről, másik internet elérésről, ahol még a szolgáltatók is különböznek, az eredmény ugyan ez.
6

Net

janoszen · 2009. Feb. 11. (Sze), 10.54
A változat: nagyon el van csettintve a configban valami (lásd fentebb)
B változat: valami halódik a gépben
C változat: a gép valami second grade, sávszél-overbooking társaságon keresztül van bent a szerverteremben.


Írj egy mailt a címmel, rányitok egy BIX-közeli helyröl, ha gondolod.