Röviden: a következő nagyjából hat hónapban több változtatást és fejlesztést hajtunk végre a LoL-kliens háttér-infrastruktúráján. Az eredmények nyomon követéséhez két fő teljesítménymutatóhoz tűztünk ki célokat: a kliens rendszerindítási ideje (meddig tart, amíg betöltődik a kliens) és a hősválasztás véglegesítéséhez szükséges idő. A mutatók javítása közben elő fog kerülni a programhibák, összeomlások stb. kérdése is. A lényeg tehát, hogy szeretnénk helyrehozni a klienst.

„Riot, mikor akarjátok kijavítani a klienst?”

Sokan feltettétek ezt a kérdést. A kliens nincs túl jó állapotban. Túl sok a programhiba, túl sok a lag (különösen a hősválasztásnál), és ezek mellett még számos egyéb probléma is akad, például memóriavesztés, összeomlások, lefagyások és így tovább. Korábban is vállaltuk, hogy rendbe tesszük a klienst, a problémák viszont nem szűntek meg.

Ezért ezúttal más megközelítést alkalmazunk.

Nem homályos általánosságokban beszélünk a terveinkről, hanem konkrét teljesítménycélokat tűzünk ki, továbbá a következő hat hónapra tervezett intézkedések listáját is megosztjuk veletek.

Először is tekintsünk át néhány, a közelmúltban elért teljesítményjavulást, valamint az ezekhez kapcsolódó adatokat, amelyek útmutatóul szolgálhatnak a későbbi fejlesztésekhez.

A KLIENS, SZÁMOKBAN

Tavaly olyan eszközökkel bővítettük a klienst, amelyek lehetővé teszik egyes alapvető teljesítménymutatók nyomon követését, például hogy meddig tart a kliens elindítása és teljes üzemképessé válása (tehát a „rendszerindítás”).

Szeretnénk, ha a rendszerindítás 15 másodpercnél kevesebb időt venne igénybe, még a lassabb gépeken is. Jelenleg azonban azt látjuk, hogy egyes játékosoknak háromszor, vagy akár négyszer ennyi ideig kell várniuk.

Egy másik fontos mutató a „hősválasztás véglegesítésének” ideje. Ez alatt azt az időt értjük, ami a gombra való kattintás és a hős véglegesítésének kliensbeli regisztrációja között telik el. Az alábbi diagramon a hősválasztás véglegesítésének átlagos válaszidejét ábrázoltuk a 9.22-es (narancssárga vonal) és a 10.2-es frissítés során (kék vonal). A véglegesítés idejét ezredmásodpercben (ms) mérjük.

A diagram egyértelműen mutatja, hogy a különböző játékosok mennyire eltérő válaszidőt tapasztalhatnak. A kliens teljesítménye természetesen függ a számítógép gyorsaságától is. Ha például kevesebb mint 200 ms kell a véglegesítéshez, akkor a géped a felső 10. percentilisbe (százalékos küszöb) tartozik, vagyis gyorsabb válaszidőt tapasztalsz, mint az összes játékos 90%-a. Hasonlóképpen, ha a válaszidő meghaladja a 800 ezredmásodpercet, a 90. percentilisbe tartozol, vagyis a kliens nálad lassabban fut, mint az összes játékos 90%-ánál.

Világosan látszik, hogy a véglegesítési idő jóval kedvezőbben alakult a 10.2-es, mint a 9.22-es frissítés során. Ennek legfőbb oka, hogy a 9.23-as frissítés alkalmával frissítettük a Chromium-verziót, amelyen a kliens fut. Ez jelentős javulást hozott, de szerintünk sokatok esetében még így is túl lassú a kliens.

Hogy pontosabban szemléltethessük a problémát, nézzük meg néhány konkrét csoportban a hősválasztás véglegesítésének időbeli alakulását.

Mint láthatjátok, a kék vonal az 50. percentilist, vagyis a „medián” játékosokat mutatja. A medián játékosok válaszideje jelentősen csökkent, ami jó hír. De láthatjuk, hogy a medián játékosok válaszideje még 2020 elején is 300 ms körül alakult. Nem rossz, de érezhető késést jelent.

A 70. percentilisbe tartozó játékosok (zöld vonal) is jelentős javulást tapasztalhattak a közelmúltban, de a válaszidejük így is átlagosan 450 ms maradt. Ez már közel fél másodperces késés, ami sokkal több annál, mint ami egy korrekt számítógépen elvárható lenne.

És most lássuk a borzalmat, amelyet a 90. percentilis (narancssárga vonal) kénytelen elviselni. Értelemszerű, hogy ők a többségnél lassabb válaszidőt fognak tapasztalni. De a 800 ms így is nagyon magas érték, pedig ez már a Chromium-frissítés utáni állapot.

Szóval! Beszéljünk arról, hogy mit tervezünk tenni.

MIRE FÓKUSZÁLUNK A JÖVŐBEN?

Két konkrét, hosszú távú célt tűztünk ki prioritásként a kliens teljesítménye terén:

1. Rövidebb, legfeljebb 15 másodperces rendszerindítási időt szeretnénk, még a 90. percentilisbe tartozó játékosok számára is. Ez háromszoros vagy négyszeres gyorsulás lenne a mostanihoz képest.
2. Szeretnénk, ha a hősválasztás véglegesítésének válaszideje 100 ms körüli értékre csökkenne a 90. percentilisbe tartozó játékosok számára. Ez nyolcszor lenne gyorsabb a mainál.

Tudjuk, mire gondoltok. Mi a helyzet a programhibákkal? És az összeomlásokkal, a memóriavesztéssel?

Miért ez a kettő a legfontosabb? A válasz egyszerű: a rendszerindítási idő és a hősválasztás véglegesítésének felgyorsításához bizonyos alapvető változtatásokra van szükség a kliens architektúrájában. Úgy véljük, hogy lehetőségünk lesz a programhibák, a memóriavesztés és az összeomlások javítására, miközben a kitűzött célok elérésén dolgozunk.

A hősválasztás „fekete képernyős” hibája és a rúnaoldalak nem megfelelő mentése két olyan probléma, amelyet orvosolni tervezünk a folyamat részeként. Szeretnénk jó előre tisztázni, hogy ez hosszú időt fog igénybe venni. Jelenleg egy hat hónapos időszakkal tervezünk, amely alatt remélhetőleg érezhető javulást tudunk elérni. De a hosszú távú célok elérése ennél is többet vehet igénybe.

Ezek a célkitűzéseink, de nem biztos, hogy sikerül elérni őket. Azért osztjuk meg veletek a konkrét célokat, mert szeretnénk visszaszerezni a kliensbe vetett bizalmat, és ehhez minden korábbinál átláthatóbban kell dolgozunk.

Persze adja magát a kérdés, hogy pontosan hogyan szeretnénk elérni a kitűzött célokat?

HOGYAN SZERETNÉNK ELÉRNI A KITŰZÖTT CÉLOKAT?

Eddig két jelentős problémát találtunk az architektúrában, amely hozzájárulhat a lassú rendszerindításhoz. Az első a beépülőmodul-architektúra, amely a kódot a kliens számára könnyebben felhasználható részekre bontja. Ez az architektúra túlságosan felduzzadt, ahogy újabb és újabb funkciókkal bővítettük a klienst. A második a felhasználói felületet működtető Javascript-keretrendszer (azaz Ember) túlterheltsége.

A kliens jelenleg túl sok beépülő modult és Ember-alkalmazást használ. A kliens rendszerindítási folyamata során 41 különböző beépülő modult és 16 alkalmazást kell betölteni. Ezek elindítása egyenként 100 – 800 ezredmásodpercet vesz igénybe. Ez nem túl jó.

A terv az, hogy ezeket a beépülő modulokat és alkalmazásokat kevesebb (és elméletileg hatékonyabb) beépülő modulokba és alkalmazásokba vonjuk össze. Elsősorban azokkal foglalkozunk, amelyek a rendszerindítás során kezdenek futni, mivel véleményünk szerint ezeken keresztül érhető el a legnagyobb javulás a kliensben.

1. FÁZIS: RENDSZERINDÍTÁS

Jelenleg sok játékosunknak akár 40 másodpercet is igénybe vehet a kliens rendszerindítása. Ha te is közéjük tartozol, akkor tudod, hogy ez mennyire lassú és döcögős folyamat. Ráadásul ha összeomlik a kliens, mindezt újra végig kell szenvedned.

A rendszerindítás során futtatott beépülő modulok és alkalmazások a kliens számos funkciójára hatással vannak, például az értesítésekre, a barátok listájára és a gyűjtemény lapra. Tehát a kitűzött hosszú távú cél a rendszerindítási idő 15 másodperc alá csökkentése a 90. percentilisbe tartozó játékosok számára, a folyamat során számos hibát és kevésbé hatékony elemet fogunk javítani, ami éreztetni fogja a hatását a kliens minden funkciójában.

A rendszerindítással kapcsolatos munkálatok első néhány hónapja után kiértékeljük, hol tartunk a céljaink teljesítésében, és (talán már tavasz végén) áttérhetünk a hősválasztás körüli munkára.

2. FÁZIS: A HŐSVÁLASZTÁS

A hősválasztás működéséhez további beépülő modulok és Ember-alkalmazások szükségesek. Leegyszerűsítve, a hősválasztó képernyőn történő minden művelet egy újabb alkalmazást hoz létre. A hősök cseréje mindjárt kettőt is. Az idézői varázslatok módosítása szintén.

Minél tovább játszol egyhuzamban a LoL-lal, annál több alkalmazás halmozódik fel, így egyre nagyobb lesz a lag. A gondot tovább fokozza, hogy a hősválasztó képernyőn végrehajtott műveletek jelentős része a szervereinkkel való kommunikációt igényel, így az egészre rárakódik a hálózati késés is.

A hősválasztással kapcsolatos legnagyobb, alapvető probléma az, ahogy a háttérrendszereink az adatokat kezelik. A hősválasztás jelenlegi architektúrájával rengeteg adatot lehet átküldeni a rendszereinken. Ha például a Riot kénytelen letiltani egy hőst a rangsorolt játékban, akkor az intézkedés szinte azonnal érvényesül majdnem az összes játékosnál, beleértve azokat is, akik éppen a hősválasztó képernyőn vannak a letiltás pillanatában.

Ez tehát egy rendkívül hatékony rendszer, cserébe viszont rengeteg lóerőre van szüksége. És a jelenlegi kialakításban túl sok a felesleges átjáró és szűk keresztmetszet. Így gyakran rengeteg adatot renderel újra a rendszer egyetlen apró bemenet változása miatt. Ez csúnyán lerontja a kliens felhasználói élményét.

Ennek javításához alapvetően át kell alakítani a hősválasztási háttér-infrastruktúra működését. Át kell dolgozni a módot, ahogy az adatok a szerverről a kliensen át eljutnak a hősválasztő képernyőig, ami elég időigényesnek ígérkezik.

Vannak ennél is nagyra törőbb, hosszú távú céljaink is: például szeretnénk elérni, hogy a kliens egyetlen Ember-alkalmazást használjon beépülő modulok nélkül, még hatékonyabbá téve ezáltal a hősválasztást. De rövid távon beérjük annyi változtatással, hogy a kliens a kitűzött, fent leírt paraméterekkel működjön.

Nehéz megjósolni, hogy mennyire leszünk közel a „jó” eredményhez a hat hónap leteltével. De reményeink szerint addigra jelentős haladást érünk el, és sikerül azonosítani a szükséges további lépéseket.

TOVÁBBI LÉPÉSEK

Néhány havonta jelentkezni fogunk fejlesztői naplókkal, amelyekben beszámolunk arról, hogy milyen teljesítménymutatókat sikerült elérni, és hogy szükséges-e módosítani a projekt időtartamát.

Kívánjatok nekünk szerencsét! És köszönjük, hogy a LoL játékosai vagytok. Hamarosan ismét találkozunk.