ugrás a tartalomhoz

php sávszélesség mérés

winston · 2007. Nov. 2. (P), 16.30
egy olyan oldalt próbálok kialakítani, ahol még az oldalgenerálás során (php) jó lenne tudnom, legalább nagyságrendileg (modem, adsl, t1...), hogy a kérő sávszélessége mekkora. erre kéne nekem valami ötlet, elsődlegesen php és/vagy apache felhasználásával, úgy, hogy túl nagy teljesítményromlás nélkül meg tudjam állapítani a sávszélességet. (a megoldások amiket eddig találtam, vagy nem php-alapúak, és/vagy pedig nagyon soká tartanak és e miatt nem lehet őket, csak külön kimérő oldalként használni. megelégszek jóval kisebb pontossággal is, csak a nagyságrend érdekel) van erre valakinek valami ötlete, vagy ismer olyan megoldást, ami a fentieknek megfelel?

köszi a válaszokat,
w.
‹ flash-php-mysql kommunikáció chat kialakításához adat kuldes form nelkul ›
 ■
1

PHP

janoszen · 2007. Nov. 2. (P), 17.00
Legtriviálisabb megoldás, hogy letöltetsz kliens oldalon egy mondjuk 200 kB-os fájlt és abból extrapolálsz. Persze, ez idő... egyébként meg be tudsz regelni DNS tartományokat MaO-n, amik egyértelműen ADSL vagy egyértelműen modemes kapcsolatok, a többit kell csak ellenőrizd.
2

aktuális szabad sávszél

winston · 2007. Nov. 2. (P), 18.39
a terület alapján az jó ötlet. a baj, hogy ugye lehet, hogy aktuálisan éppen töltenek le, vagy valami, így az aktuális sebesség torzulhat. de az ötlet tetszik.
3

Load

janoszen · 2007. Nov. 2. (P), 18.50
Szerver loadot is nézhetsz...
4

Poénból töltögetsz?

Nagy Gusztáv · 2007. Nov. 2. (P), 23.19
Én nem szeretnék olyan oldalnak a látogatója lenni, amelyik "poénból" 200 Kilót töltöget a sávszélességemből.
5

Videó

janoszen · 2007. Nov. 3. (Szo), 10.02
Winston esetében - ha jól tudom/sejtem - videó streameléshez sávszélesség megállapítás a célja. Egyrészt, ott vannak a poolok, amikkel kb. egész MaO 90%-át le tudod fedni, a többinek backupnak meg ott van a mérés, ami alapján bővíteni lehet a poolt. Ergó, egyrészt az a 200k a videó mellett föl se tűnik másrészt ritkán fog előfordulni.

Nyilván arra nem érdemes használni, hogy a honlapod betöltésekor megnézed a sávszélt és megfelelő tartalmat szolgálsz ki, mert ... inkább nem magyarázom. :)
6

A nagyok

vbence · 2007. Nov. 3. (Szo), 10.23
Az etalonnak is tekinthető http://apple.com/trailers megkérdi mekkora változatot szeretnél a videóból. Szerintem ez a plusz egy kattintás nem jelent akkora kényelmetlenséget, hogy elriassza a potenciális nézőket, másrészt én is gyakran választok kisebbet, mint ami még kiférne a csövön ilyen-olyan okokból. Meg néha nagyobbat is.
7

speci...

winston · 2007. Nov. 3. (Szo), 10.45
sajnos nem poénból teszem bele a funkciót a siteba, hanem benne van a specifikációban, így igazodnom kell hozzá. szívem szerint az apple módszerrel csinálnám, és is szeretem, hogy ott választani tudok. (itt is, csak fel kell ajánlani egyet) ugyan elég jó sávszélem van, mégis mindig medium sizeban nézem. a 200k-s példát azért akarnám elkerülni, mert az tényleg sok, úgy szeretném, hogy nem észrevehető mennyiségű extra forgalmat generáljon. kis adatcsomagra gondoltam, vagy ilyesmi, mert nem kell teljesen releváns értékelés. az jutott eszembe még, hogy esetleg apacheból el lehetne e kapni azt a sávszélt, amivel mondjuk a css fileok, vagy az oldalon található képek/flash lejátszó megy át. mert akkor nem kéne külön valamit átküldeni mérési céllal.
8

Egy megoldás...

janoszen · 2007. Nov. 3. (Szo), 12.16
Ha előtte kiszolgálsz valamilyen tartalmat, persze, lehet mérni a sávszélt. Még csak apacs se kell hozzá, csak egy JavaScript, ami visszaszól onload-kor.
9

Jó ötlet

vbence · 2007. Nov. 3. (Szo), 12.47
Egész jó ez a "painless" megoldás. Az egyetlen baj, hogy nem lehet egyértelműen sávszélt számolni (requestek, latencia), de egy tetszőleges időt meg lehet állapítani (pl ha több, mint 6 másodpercig töltődött az oldal, akkor a gyengébb verziót tesszük defaultnak).

Más: hogy kerülhet bele ilyen dolog egy specifikációba? Egyrész nem jó praktika, mert ha az lenne, akkor máshol is ezt használnák. Másrészt meg nincs is rá megbízható módszer, úgyhogy ha szigorúan vesszük, akkor megoldhatatlan feladat. - Szóval az ilyen dolgokról a hozzáértőnek kell lebeszélnie a megrendelőt, mert az ugye nem ért hozzá.
11

speci

winston · 2007. Nov. 4. (V), 21.15
mint fent mondtam, nem is kell pontos sávszél. csak megközelítőleg, az teljesen elég.

más: igen, szépen hangzik, hogy a (számomra) tökéletes (, nekem teljesen tetsző) specifikáció, egyebek, de pár év a szakmán belül meggyőzött róla, hogy ilyen csak egy ideális világban van. ami a megoldhatatlanságát illeti: van rá megoldás, csak én az általad is említett "painless" felé szeretném terelni a dolgokat, hogy életképes legyen. (meg lehetne úgy is oldani, hogy bedrótozok elé egy sávszélmérést, de akkor csak azzal elmenne fél perc, vagy akár egy perc is). a megrendelés belső céges munka.

úgyhogy a jelenlegi álláspontom, hogy bizonyos engedményekkel (pl. némi pontatlanságot beengedve) akár még életképes is lehet.
10

sima kép kiszolgálás PHP-ból?

Hodicska Gergely · 2007. Nov. 3. (Szo), 13.21
Az nem elég Neked, hogy mondjuk az oldal végére beszúrsz egy kép hivatkozást, ami egy PHP-ra mutat. Ez kiszolgálja kisebb darabokban a képet, és bejegyzi az infót a látogató sessionjébe.

Amit itt még trükközhetsz, ha mondjuk nem szeetnéd az onload idejét kitolni ezzel a lekéréssel, hogy JS-ből teszed ki a képet, illetve teszel mellé egy noscript taget is, hogy kikapcsolt JS esetén se legyen gond.

Ha ezt a megoldást választod, akkkor még arra kell figyelned, hogy zárd le a sessiont "kézzel" a template kiszolgálása előtt (amikor már az üzleti logika lezajott), különben ha a session lezelésbe nincs lokkolás beépítve (nem nagyon szokott), akkor támadhatnak gondjaid.


Üdv,
Felhő
12

kép?

winston · 2007. Nov. 4. (V), 21.18
lehet, hogy én nem olvastam figyelmesen, de mit érek el vele, hogy képet szolgálok ki? mármint a konkrét kép kiszolgálásával. arra gondolsz, hogy ezt, mint "mérőjelet" szolgálom ki? (akkor már inkább az oldalon fellelhető valamelyik, egyébként is kiszolgált képpel trükközöm meg)
15

diszkrét, transzparens

Hodicska Gergely · 2007. Nov. 4. (V), 21.44
Azt nyered vele, hogy ez a megoldás teljesen transzpaarens a mostani alakamazásod szempontjából, valamint nem JavaScript függő. A plusz képre meg azért gondoltam, mert valszeg nincs ekkora méretű design elem, plusz megint csak nincs összekötve az elkalmazással.


Üdv,
Felhő
20

De JS függő

janoszen · 2007. Nov. 5. (H), 10.51
Sajnos igenis JS függő. A PHP attól kezdve hogy kitolta a kimenetre a képet mint adatot, nem lát semmit ergó csak azt tudja mérni, hogy mennyi idő telt el a request megkezdése és a kép kiszolgálása között, azt már nem látja hogy mennyi ideig utazik a kép a neten. Kérlek, javíts ki ha tévedek, de szerintem itt JavaScripttel meg kell nézni, hogy mikor érkezett meg a kép.

Egyébként szerintem, ezzel kombinálva még mindig az a legjobb megoldás hogy a gyakori reverse DNS-eket, IP poolokat előre bedrótozni egy adatbázisba, hogy ne kelljen ezzel se szarakodni.
21

közvetlen kapcsolat

Hodicska Gergely · 2007. Nov. 5. (H), 14.25
Ha a fenti esetről van szó (tehát nincs a kliens és a szever között proxy), akkor a böngésző elkezdi letölteni tőled a tartalmat, nem tudod gyorsabban kitolni, mint ahogy ő fogadni képes, tehát egy nagyobb fájl esetén (erről volt szó a threadben) meg tudod becsülni a kliens sávszélességét (szerintem, konkrétan nem próbáltam még ilyesmit).


Üdv,
Felhő
13

faramuci megoldás

winston · 2007. Nov. 4. (V), 21.20
közben eszembe jutott egy faramuci megoldás (Gergely válaszát olvasva. ha valami hasonlót próbáltál leírni, akkor bocsi, de nem értettem ki belőle :)). szóval: a php script elején fellövök egy időmérést. ezt egy hidden mezőbe beleteszem, vagy valamilyen módon átadom. ezután onload, js-ből hívok egy újabb időmérést, és a két szám különbségét elosztom egy átlagos mért oldalmérettel. ezzel közelítő számhoz juthatok. nem tudom, hogy ez gyakorlatban mennyire életképes, mindjárt kipróbálom.
14

Szerintem erre gondolt

vbence · 2007. Nov. 4. (V), 21.42
<html>
<head>
    <script> var t = new Date().getTime();</script>
</head>
<body onload="alert(new Date().getTime() - t);">

...

</body>
</html>
A szerver idejét nem hasonlíthetod össze a kliens idejével. A kód végén (body után) nincs értelme mérni, mert nem tudhatod, hogyan pufferelődik az adat (plusz még az esetleges proxy szerverek) - lehet, hogy az egyész oldal egyszerre jön meg, lehet, hogy 8k-s csomagokban stb...

Ezzel a fenti megoldással a képeket is méred, meg benne van a kiszolgálás ideje stb... ezért mondtam, hogy találj ki egy fantázia-számot, mondjuk 10 másodperc, és ha ennél több, akkor lassúnak tekinted a kapcsolatot.
16

onload nem

winston · 2007. Nov. 4. (V), 21.59
igen, hasonlóra jutottam, de nem túl jó számok jöttek ki, mert igen: túl sok minden van benne. ezért mondtam, hogy faramuci. a képekre: egy olyan kitalált átlagoldalméretre gondoltam, amit elosztok az idővel, és ami az oldalak átlagmérete körül van, képekkel. de nem, ez így valóban nem lesz jó, csak eszembe jutott, és kipróbáltam.

a fantáziaszámmal megpróbálok még belőni valami közelítőértéket, de ott is félek, hogy túlzottan torzítódik. aztán majd meglátjuk. (bár igazából csak összevissza 3 tartományra kell felosztanom a dolgot: "lassú-átlagos-gyors" szintekre, annyira tán nem torzít)
17

onload

vbence · 2007. Nov. 4. (V), 22.19
Amire vigyázod kell az onload-nál, hogy ha külső widget-eket (vagy google analitycs-et) használsz, az elronthatja (illetve rapszódikussá teheti) az eredményt, mivel beleszámít az onload-ba, ugyanakkor más (esetleg terhelt) szerverről jön.

Megint más: Ha a teljes oldal töltődését nézed, akkor a sebességteszed eredendően magába fogja foglalni a szervered terhelését is, ami videók kiszolgálásakor igen csak szóba jöhet. Így elsőre nem tudom megtippelni, hogy milyen időkről van szó, ha túlterhelt a szerver (sokan nézik) valószínűleg lassabban jön be az oldal is, és ilyenkor a szerver hajlamosabb lesz a kisebb sávszálességgű videókat választani, ami jó :)
18

nem egészen

Hodicska Gergely · 2007. Nov. 4. (V), 22.57
Arra gondoltam, hogy simán egy img tag kerül az oldal végére, ami egy PHP-ra mutat. Ez a PHP fájl szolgál ki a usernek egy valamekkora méretű képet, és a kiszolgálás idejéből nyert infó alapján elmenti sessionbe, hogy a user melyik csoportba tartozik. Ennek persze hátránya lehet, hogy nem feltétlenül a user áll kapcsolatban a szerverrel, hanem valami proxy.

A szerver idejét nem hasonlíthetod össze a kliens idejével.
Erre nincs is szükség, hisz leraksz egy időpontot (ami a szerveré), és ezt visszaküldöd a szervernek, ami meg tudja a kapott adatból és az aktuális időből, hogy mennyi idő telt el.


Üdv,
Felhő
19

Blokkolás és a puffer

vbence · 2007. Nov. 4. (V), 23.41
Bevallom, arról nem voltam meggyőződve, hogy a readfile vagy az echo blokkolja a végrehajtást amég a puffer tele van. Bár szerintem az utolsó puffernyi adat így is kimarad a mérésből.