Sz\u00e9pen, de nem t\u00fal lassan k\u00f6zeleg az idei YRoNS-konferencia (l\u00e1sd. el\u0151z\u0151 posztok), \u00edgy az informatikai rendszerekkel is haladni kell. A fejleszt\u00e9s r\u00e9sze az alkalmaz\u00e1s \u00e9les teszt\u00fczeme is (ez azt jelenti, hogy az esem\u00e9ny el\u0151tt egyszer \u00e9lesben is lepr\u00f3b\u00e1ljuk a rendszert, hogy ne a konferencia el\u0151tt der\u00fclj\u00f6n ki a gond).<\/p>\n
<\/p>\n
A tesztre egy m\u00e1sik (az YRoNS-hoz nem kapcsol\u00f3d\u00f3), konferenci\u00e1n ker\u00fclt sor. A rendszert teljes eg\u00e9sz\u00e9ben sajnos nem tudjuk letesztelni, mivel nem volt sz\u00fcks\u00e9g ebben a helyzetben a t\u00f6bbi alkalmaz\u00e1s-funkci\u00f3ra (\u00fczenetk\u00fcld\u00e9s, n\u00e9vjegyk\u00e1rtya-megoszt\u00e1s, esem\u00e9nynapt\u00e1r).<\/p>\n
A f\u0151 k\u00e9rd\u00e9s(em) az volt, hogy vajon m\u0171k\u00f6dni fog-e a websocket alap\u00fa kommunik\u00e1ci\u00f3, illetve hogy milyen hat\u00e1sa lesz a nagy terhel\u00e9snek (egyszerre 70-100 ember fog l\u00f3gni a rendszerben).<\/p>\n
A rendszer a m\u00e1r lefejlesztett QnA modul fejlettebb v\u00e1ltozata, a sima WebSocket kommunik\u00e1ci\u00f3 helyett socket.io-t haszn\u00e1l (ami szint\u00e9n websocketen alapul, de van benne egy long-polling fallback is).<\/p>\n
A websocket egy alacsony v\u00e1laszidej\u0171 (nagyon gyors), bi-direkcion\u00e1lis (k\u00e9tir\u00e1ny\u00fa) TCP alap\u00fa protokoll, amit f\u0151leg olyan estekben haszn\u00e1lunk, amikor nagyon gyorsan kell kommunik\u00e1lnunk a szerver \u00e9s kliens k\u00f6z\u00f6tt. Nek\u00fcnk ebben a helyzetben pontosan erre van sz\u00fcks\u00e9g\u00fcnk!<\/p>\n
De eml\u00edtett\u00fck m\u00e9g a long pollingot is, ez is hasonl\u00f3. A long polling eset\u00e9ben a kliens egy HTTP-k\u00e9r\u00e9st k\u00fcld a szerver fel\u00e9 (\u00e1ltal\u00e1ban), de nem kap r\u00f6gt\u00f6n v\u00e1laszt. A szerver csak akkor v\u00e1laszol, ha adatbeli v\u00e1ltoz\u00e1s t\u00f6rt\u00e9nt, vagy id\u0151t\u00fall\u00e9p\u00e9s van. Ilyenkor a kliens automatikusan \u00fajrak\u00e9ri az adatokat.<\/p>\n
Sz\u00e1momra els\u0151re nagyon meglep\u0151 dolog t\u00f6rt\u00e9nt: minden j\u00f3l m\u0171k\u00f6d\u00f6tt, semmit sem kellett csin\u00e1lnom… Na persze ennek is kellett t\u00f6rt\u00e9nnie, legal\u00e1bb is ezt rem\u00e9ltem.<\/p>\n
A rendszerben kb. 80 ember volt egyszerre, 15 m\u00e1sodperc alatt adt\u00e1k le szavazataikat egy t\u00e9m\u00e1ban (ez olyan 5 websocket frame m\u00e1sodpercenk\u00e9nt). Ez \u00e9rdekes, mert amikor ugyanezt a rendszert tesztelt\u00fck, nem tudtunk 3.7 k\u00e9r\u00e9s per\/m\u00e1sodperc f\u00f6l\u00e9 menni HTTP haszn\u00e1lat\u00e1val (nem b\u00edrta ugyanez a hardver). Ebb\u0151l is l\u00e1tszik, hogy a websocket framek kisebbek, mint a HTTP-k\u00e9r\u00e9sek.<\/p>\n
P\u00e1r cikkel ezel\u0151tt le\u00edrtam, hogy minden infrastrukt\u00fara-elem folyamatos monitoring alatt \u00e1ll, \u00edgy nagyon sz\u00e9p grafikonokat tudtam produk\u00e1lni az esem\u00e9nyekr\u0151l.<\/p>\n
A lenti grafikonokon l\u00e1tszik, hogy a nagy terhel\u00e9s ellen\u00e9re kicsi, alig m\u00e9rhet\u0151 az er\u0151forr\u00e1s-haszn\u00e1lat. Ami nekem meglep\u0151 volt, hogy nem volt akkora a h\u00e1l\u00f3zati forgalom, mint sima HTTP-haszn\u00e1lata eset\u00e9n (de ez m\u00e1r nem meglep\u0151, fentebb \u00edrtam is r\u00f3la).<\/p>\n
![\"\"](\"https:\/\/mikulalajos.hu\/wp-content\/uploads\/2024\/02\/image_67144961-Nagy-300x225.jpg\")