Wordpress-re CDN mindig jó dolog?

Apdex index alapértelmezetten 3mp-et mond még jó válaszidőnek. Afelett már romlik a felhasználói élmény, amivel felhasználókat vesztesz. Persze, függ attól, hogy mit mondunk jó időnek azaz mi az a limit, ami most 3mp.

[link]

Tehát a 7-8mp az már zöld-sárga-piros zónákban nézve már a sárga végén, piros elején jár.

Pl. egy monitorozó program által mért Apdex index minősítés: [link]

Én a 3mp oldaltöltést is sokallom.

Első alkalommal még csak-csak elmegy, ha utána gyors, ~1mp vagy alatti az oldalváltás.

AJAX -al ez 0.2 másodpercre lehet átlag csökkenteni,

WebSocket -el, pedig 0.05 másodpercre, adat csere 0.01s a többi renderelés.

Relatív mit nevezünk gyorsnak. Ez sok mindentől is függhet. Szerver hardvertől, adatbázistól, hálózattól, felhasználó egy pillanatnyi számától, stb.

Ki kell, hogy ábrándítsalak, de 1ms soha nem lesz. Van egy hálózati latency alapból + szerver feldolgozás + adatbázis, ha van. Ha tényleg gyors a rendszer, akkor legjobb esetben is 20-30ms.

WebSocket dettó.. Csak a TCP kapcsolatot nem bontja, szóval azt megspórolod. A többi idővel így is úgy is számolni kell.

Amúgy: 3mp az átlag emberi tűrés képesség, hogy ne spammelje a refresht. 200ms válaszidőt még gyorsnak érez az ember, 500ms-nél érződik, hogy picit gondolkozik a rendszer.

#3: WebSocket esetén 10ms alatti a hálózat latency.

Socket kisméretű adat, így szintén ~20ms -ban meg van.

Persze, ez nem teljes oldalt, csak elérni kívánt tartalmat tölti be.

Azért ilyen gyors, mert nem kell kapcsolatot újra felépíteni,

nem fut le a teljes FW inicializálása a szerveren,

csak az egy függvény hívás ~ lekérdezés és annak válaszának közvetlen vissza küldése.

Több időt vesz el, a JS adat feldolgozás, és HTML - CSS megrajzolása.

Mivel elég bonyolult egy ilyen kiépítése, így ritkán alkalmazzák.

Egy folyamatos kétirányú kapcsolat kliens és szerver közt.

Kicsi, kisebb mint 64Kbyte méretű adatcsomagokkal lehet kommunikálni.

Gyors, mivel folyamatos kapcsolat, tehát nem kell várni a kapcsolat kiépülésére.

Folyamatosan fut, szerver szolgáltatás, így már a memóriába van töltve a FW jelentős része, osztályok - függvények készen állnak a meghívásra, míg hagyományos HTTP kérésnél minden lekérdezésnél újra tölti az egészet.

És mivel két irányú így a szerver irányából is érkezhet állapot frissítés, külön kérés nélkül.

pl. egy chat esetén, mikor elküldöd a partner egyből meg is kapja.

míg HTTP kéréseknél, elküldöd, majd a partner akkor kapja meg, ha lekérdezi, van -e új bejegyzés.

Ahogy néztem nem, keretrendszernek kell támogatni, mert ugyanúgy http-re üll rá. Nekem is új volt a websocket, így megtanultam.

Jópofa, hogy lehet broadcast, multicast-olni üteneteket vagy spaciálisan egy usernek küldeni. Csak azonosísd. :D

Nagyon bonyolítja a kódot.. a websocket. Mert nem küldök-kapok van, hanem felkell iratkozni egy csatornára, ahol fogadsz és van külön publish, amivel küldesz. Tehát egy restapi-val ellentéten szét van szedve a jövő és menő.

Szerintem a websocket olyan feladatokra jó, mikor a szerverre vársz, és nem akarsz "kész van már?" vagy "van új adat?" kérdéseket küldeni másodpercenként, mindezt sok bönkészőből ami szerver oldalon qrva sok request. Inkább szerver szól, hogy van új adat.

Ahogy néztem külföldi cégek webalkalnazásait a websocket nem elterjedt. Folyton időközönkénti http kéréseket láttam.

Végeredményben monitorozni kell a szervert, hogy elbírja-e csak http-vel vagy kell a websocket.

Én a saját projektembe bele tettem, de inkább ott a szerver küld (csak feliratkozások vanbak) és a kliens maradt a http kéréseknél.