Riot szczerze o kliencie LoLa „Ma zbyt wiele błędów, lagów i problemów”. W końcu zaczyna się jego naprawa

W skrócie: w ciągu mniej więcej kolejnych sześciu miesięcy wprowadzimy kilka zmian i ulepszeń w infrastrukturze klienta League. Żeby monitorować skuteczność tego procesu, będziemy posługiwać się dwoma głównymi wskaźnikami wydajności klienta: czasem bootstrapu klienta (czyli tym jak długo trwa uruchamianie się klienta) i czasem zatwierdzania bohatera. W trakcie prac nad ulepszaniem tych wskaźników, będziemy również zajmować się usuwaniem błędów, przyczyn zawieszania się itp. Mówiąc najprościej, naszym celem jest naprawienie klienta.

„Riot, kiedy zamierzacie naprawić klienta?”

To pytanie, które zadajecie bardzo często. Ponieważ klient nie jest w dobrym stanie. Ma zbyt wiele błędów, zbyt wiele lagów (szczególnie na etapie wyboru bohatera) i całe mnóstwo problemów, takich jak utraty pamięci, awarie, zawieszanie się i tak dalej. Już wcześniej obiecywaliśmy, że zajmemy się klientem, jednak problemy pozostały.

Dlatego chcemy spróbować czegoś innego.

Zamiast ogólnikowo mówić o naszych planach, dzisiaj przedstawiamy konkretne cele związane z wydajnością działania i precyzyjnie sformułowane szczegóły zmian, które planujemy wprowadzić w ciągu najbliższych sześciu miesięcy.

Najpierw porozmawiajmy jednak o niedawno wprowadzonych usprawnieniach wydajności i przeanalizujmy kilka konkretnych liczb, które będą służyć za punkty odniesienia dla naszych przyszłych ulepszeń.

Klient w liczbach

Pod koniec zeszłego roku dodaliśmy do klienta kilka narzędzi, które pozwalają nam śledzić podstawowe wskaźniki wydajności, takie jak np. czas potrzebny na uruchomienie się klienta i osiągnięcie przez niego pełnej funkcjonalności (czyli „bootstrap”).

Chcielibyśmy, aby bootstrap trwał maksymalnie 15 sekund, nawet w przypadku stosunkowo wolnych komputerów. Jednak wiemy, że aktualnie niektórzy gracze muszą czekać na zakończenie bootstrapu nawet trzy lub nawet cztery razy dłużej.

Kolejną ważną rzeczą, którą śledziliśmy, jest czas „zatwierdzania wyboru bohatera”. Jest to ilość czasu — liczona od momentu kliknięcia przycisku — której klient potrzebuje na zarejestrowanie faktu zatwierdzenia bohatera przez gracza. Na poniższym wykresie zobaczycie średnie czasy reakcji na zatwierdzenie wyboru bohatera w patchu 9.22 (pomarańczowa linia) i w patchu 10.2 (niebieska linia). Czas reakcji na zatwierdzenie wyboru bohatera jest podawany w milisekundach.

Powyższy wykres pokazuje, jak bardzo różnią się czasy reakcji na zatwierdzenie wyboru bohatera w przypadku różnych graczy. Oczywiście wydajność klienta zależy od szybkości komputera. Jeśli na przykład zatwierdzenie zajmuje do 200 ms, to komputer mieści się w 10 percentylu, a uzyskiwane czasy reakcji są szybsze niż w przypadku 90% wszystkich graczy. Podobnie, jeśli czas reakcji przekracza 800 ms, to komputer znajduje się w 90 percentylu, co oznacza, że klient działa wolniej niż w przypadku 90% wszystkich graczy.

Jak widzicie, czasy zatwierdzania znacznie się poprawiły w patchu 10.2 w porównaniu z patchem 9.22. Głównym powodem tej poprawy jest to, że w patchu 9.23 zaktualizowaliśmy wersję Chromium, z której korzysta klient. Pozwoliło nam to osiągnąć duży postęp, ale uważamy, że klient wciąż działa za wolno u wielu z was.

Żeby pokazać, co mamy na myśli, przyjrzyjmy się bardziej szczegółowo ewolucji szybkości reakcji na zatwierdzanie bohatera na przestrzeni czasu w konkretnych grupach.

Jak widzicie, niebieska linia reprezentuje 50 percentyl, czyli graczy z mediany. Duże skrócenie czasu reakcji widoczne w przypadku graczy należących do mediany jest pozytywnym wskaźnikiem. Ale jak możecie zobaczyć, na początku 2020 roku czasy reakcji na zatwierdzenie bohatera dla graczy z mediany oscylują wokół 300 ms. To nie dramat, ale wciąż jest to zauważalne opóźnienie.

Gracze z 70 percentyla (zielona linia) również odczuli ostatnio istotną poprawę, ale czasy reakcji na zatwierdzenie bohatera w ich przypadku oscylują wokół 450 ms. To prawie pół sekundy opóźnienia, czyli szczerze mówiąc, znaczne wolniej niż chcielibyśmy, aby czekali gracze korzystający z nawet nie najlepszych komputerów.

I wreszcie spójrzmy na 90 percentyl (pomarańczowa linia) w całej jego przerażającej chwale. W przypadku tych graczy czas reakcji będzie z założenia wolniejszy niż u większości. 800 ms to jednak zdecydowanie zbyt długo, a okazuje się, że nawet po aktualizacji Chromium, są gracze, którzy muszą tyle czekać.

A zatem, pomówmy o tym, co zamierzamy zrobić.

Nasz następny priorytet

Wybraliśmy dwa konkretne, długoterminowe cele w zakresie wydajności klienta, które będą naszymi priorytetami:

1. Chcemy obniżyć czas bootstrapu do około 15 sekund nawet dla graczy z 90 percentyla. To od trzech do czterech razy szybciej w porównaniu ze stanem obecnym.
2. Chcemy skrócić czas reakcji na zatwierdzenie bohatera do około 100 ms dla graczy z 90 percentyla. To około ośmiu razy szybciej niż obecnie.

Wiemy, o czym myślicie. Co z błędami? Co z zawieszaniem się i utratami pamięci?

Dlaczego traktujemy priorytetowo te dwie rzeczy? Otóż w ramach procesu rozwiązywania problemów z czasem bootstrapu i czasem reakcji na zatwierdzenie bohatera zamierzamy oczyścić i przerobić pewne podstawowe elementy architektury klienta. Uważamy, że podczas realizacji tych celów, chcąc nie chcąc naprawimy błędy, zapobiegniemy utratom pamięci i zlikwidujemy zawieszanie się.

Problemy takie jak „czarny ekran” podczas wyboru bohatera i niepoprawne zapisywanie stron run to tylko przykłady błędów, które mamy nadzieję usunąć w ramach tego procesu. Chcemy jednak bardzo jasno powiedzieć, że to wymaga czasu. Aktualnie mamy z grubsza zakreślony sześciomiesięczny plan i wierzymy, że pozwoli on nam zrobić znaczące postępy w realizacji założonych celów. Natomiast osiągnięcie zamierzeń długoterminowych zajmie prawdopodobnie więcej czasu.

To są nasze cele, ale może się okazać, że będziemy potrzebować więcej czasu. Przedstawiliśmy je wam, ponieważ wiemy, że aby odbudować wasze zaufanie do klienta, musimy bardziej przejrzyście niż do tej pory określać nasze działania.

Zapytajcie teraz, jak dokładnie zamierzamy to zrobić?

Jak zamierzamy to zrobić?

Na razie zidentyfikowaliśmy dwa główne problemy w architekturze klienta, które przyczyniają się do powolnego działania bootstrapu. Pierwszy to nasza architektura wtyczek, która pozwala nam dzielić kod klienta na łatwe w obsłudze kawałki. Ta architektura została nadmiernie rozciągnięta podczas dodawania do klienta kolejnych nowych funkcjonalności. Drugi problem to niewłaściwe wykorzystanie biblioteki Javascript (zwanej Ember), na której opiera się nasz interfejs.

Obecnie klient używa zdecydowanie zbyt wielu wtyczek i aplikacji wykorzystujących Ember. W trakcie bootstrapu klienta ładujemy 41 różnych wtyczek i 16 aplikacji. Każdy z tych elementów potrzebuje od 100 ms do 800 ms na uruchomienie, To nie jest dobry wynik.

Naszym planem jest konsolidacja wszystkich tych wtyczek i aplikacji w celu stworzenia znacznie mniejszej liczby (teoretycznie bardziej wydajnych) wtyczek i aplikacji. Zamierzamy skupić się na tych, które jako pierwsze zaczynają działać podczas bootstrapu, ponieważ uważamy, że przyniesie to najwięcej korzyści.

FAZA 1: BOOTSTRAP

Obecnie wielu graczy musi czekać aż 40 sekund na zakończenie bootstrapu. Jeśli należycie do tych graczy, wiecie, że sprawia to wrażenie bardzo powolnego i przestarzałego procesu. Oznacza to również, że gdy klient się zawiesi, restartowanie go jest równie bolesne.

Wiele elementów klienta, takich jak powiadomienia, listy znajomych, czy zakładka Kolekcji, zależy od wtyczek i aplikacji uruchamianych podczas bootstrapu. Dlatego uważamy, że chociaż naszym długoterminowym celem jest skrócenie bootstrapu do 15 sekund dla graczy z 90 percentyla, to w trakcie jego realizacji rozwiążemy również wiele błędów i nieefektywnych rozwiązań, które mają wpływ na działanie całego klienta.

Po kilku miesiącach pracy nad bootstrapem ocenimy, jak blisko jesteśmy od zrealizowania naszych celów, a potem — zapewne pod koniec wiosny — przejdziemy do pracy nad wyborem bohatera.

FAZA 2: WYBÓR BOHATERA

Wybór bohatera wiąże się z inicjowaniem wielu dodatkowych wtyczek i aplikacji opartych na Ember. Mówiąc obrazowo, niemal każda czynność wykonana na ekranie wyboru bohatera powoduje powstanie nowej aplikacji. Wymiana bohaterów generuje dwie. Podobnie zmiana czaru przywoływacza.

Im dłużej gracie w League podczas jednej sesji, tym więcej tych aplikacji nakłada się na siebie, powodując coraz większe opóźnienia. Sytuację komplikuje dodatkowo fakt, że większość działań podejmowanych podczas wyboru bohatera opiera się na komunikacji z naszymi serwerami, co powoduje dodatkowe opóźnienia podczas każdej interakcji.

Tak naprawdę podstawowym problemem procedury wyboru bohatera jest sposób zarządzania danymi przez systemy działające w tle. Aktualna architektura procedury wyboru bohatera pozwala nam przenosić za pośrednictwem naszych systemów całe mnóstwo istotnych danych. Na przykład, gdy Riot podejmuje decyzję o wyłączeniu bohatera w grach rankingowych, bohater zostaje wyłączony niemal natychmiast dla wszystkich graczy, w tym tych, którzy znajdują się w fazie wyboru bohaterów właśnie wtedy, gdy wyłączenie jest wprowadzane.

To bardzo potężny system, ale wymaga mnóstwa „koni mechanicznych”, żeby działał. Sposób, w jaki ten system jest aktualnie skonfigurowany, jest przyczyną powstawania wielu zbędnych bramek i wąskich gardeł. Dlatego często jedna mała zmiana powoduje konieczność odnowienia całej masy danych, W efekcie działanie klienta na waszych komputerach jest obarczone wieloma problemami.

Żeby to naprawić, będziemy musieli całkowicie zmienić sposób funkcjonowania działającej w tle infrastruktury obsługującej wybór bohatera. Zamierzamy zmodyfikować sposób, w jaki wszystkie dane są przekazywane przez serwer do klienta podczas wyboru bohatera, co oczywiście zajmie trochę czasu.

Mamy też inne ambitne cele długoterminowe, które mogą sprawić, że obsługa procesu wyboru bohatera będzie jeszcze bardziej wydajna — na przykład konsolidacja całego klienta do jednej aplikacji Ember bez żadnych wtyczek. Jednak na razie chcemy wprowadzić zmiany, dzięki którym działanie klienta zacznie spełniać opisane powyżej wskaźniki.

Trudno powiedzieć, w jakim stopniu po tych sześciu miesiącach uda się nam zbliżyć do stanu, który uznalibyśmy za „dobry”. Jednak uważamy, że gdy już dojdziemy do końca tego procesu, to niejako „po drodze” zrobimy wiele postępów i jasno zdefiniujemy następne kroki.

Zamierzamy co parę miesięcy weryfikować nasze postępy w ramach bloga deweloperów, przedstawiając dane liczbowe dotyczące wydajności oraz wszelkie zmiany naszego harmonogramu działania.

Życzcie nam powodzenia! Dzięki, że gracie w League. Wkrótce znów o tym pogadamy.