Szépen, de nem túl lassan közeleg az idei YRoNS-konferencia (lásd. előző posztok), így az informatikai rendszerekkel is haladni kell. A fejlesztés része az alkalmazás éles tesztüzeme is (ez azt jelenti, hogy az esemény előtt egyszer élesben is lepróbáljuk a rendszert, hogy ne a konferencia előtt derüljön ki a gond).
A tesztre egy másik (az YRoNS-hoz nem kapcsolódó), konferencián került sor. A rendszert teljes egészében sajnos nem tudjuk letesztelni, mivel nem volt szükség ebben a helyzetben a többi alkalmazás-funkcióra (üzenetküldés, névjegykártya-megosztás, eseménynaptár).
A fő kérdés(em) az volt, hogy vajon működni fog-e a websocket alapú kommunikáció, illetve hogy milyen hatása lesz a nagy terhelésnek (egyszerre 70-100 ember fog lógni a rendszerben).
A rendszer a már lefejlesztett QnA modul fejlettebb változata, a sima WebSocket kommunikáció helyett socket.io-t használ (ami szintén websocketen alapul, de van benne egy long-polling fallback is).
Mi ez a parasztvakítás?
A websocket egy alacsony válaszidejű (nagyon gyors), bi-direkcionális (kétirányú) TCP alapú protokoll, amit főleg olyan estekben használunk, amikor nagyon gyorsan kell kommunikálnunk a szerver és kliens között. Nekünk ebben a helyzetben pontosan erre van szükségünk!
De említettük még a long pollingot is, ez is hasonló. A long polling esetében a kliens egy HTTP-kérést küld a szerver felé (általában), de nem kap rögtön választ. A szerver csak akkor válaszol, ha adatbeli változás történt, vagy időtúllépés van. Ilyenkor a kliens automatikusan újrakéri az adatokat.
Mi történt?
Számomra elsőre nagyon meglepő dolog történt: minden jól működött, semmit sem kellett csinálnom… Na persze ennek is kellett történnie, legalább is ezt reméltem.
A rendszerben kb. 80 ember volt egyszerre, 15 másodperc alatt adták le szavazataikat egy témában (ez olyan 5 websocket frame másodpercenként). Ez érdekes, mert amikor ugyanezt a rendszert teszteltük, nem tudtunk 3.7 kérés per/másodperc fölé menni HTTP használatával (nem bírta ugyanez a hardver). Ebből is látszik, hogy a websocket framek kisebbek, mint a HTTP-kérések.
Pár cikkel ezelőtt leírtam, hogy minden infrastruktúra-elem folyamatos monitoring alatt áll, így nagyon szép grafikonokat tudtam produkálni az eseményekről.
A lenti grafikonokon látszik, hogy a nagy terhelés ellenére kicsi, alig mérhető az erőforrás-használat. Ami nekem meglepő volt, hogy nem volt akkora a hálózati forgalom, mint sima HTTP-használata esetén (de ez már nem meglepő, fentebb írtam is róla).
Összegzés
Összességében szerintem nagyon szépen működött a rendszer és valószínűleg ugyanilyen jól fog működni majd a későbbi “élesebb” konferencián is.
Leave a Reply