Segítség, belassultunk! - 2. rész:

Segítség, belassultunk! - 2. rész:

Az előző részben megmutattuk, hogy a Speakerhub.com projektünk üzleti szempontból alapvető funkciója a profilszerkesztő. Arra is kitértünk, hogy rövid idő alatt a profilok adatszerkezete, a mezők számának és bonyolultságának növekedésével hogyan érte el a Drupal által biztosított lehetőségek határát.

Lassú-lassú, de mi lassú?

A fejlesztés, üzemeltetés szempontjából a legnehezebben megfogható, és kezelhető felhasználói visszajelzés a lassúság volt. Folyamatosan visszakérdeztünk: melyik felhasználónál jelentkezik a lassulás? Mit csinál a felhasználó, honnan érkezik, mikor? Csak egy-egy felhasználónál jelentkezik a lassulás? Vagy mindenkinél? Mikor? Az éppen futó kódnak egy része lassú, vagy valamelyik Drupaltól független rendszer lassul be?

Néhány levélváltás után kiderült, hogy két problémánk is van, melyek megoldása más megközelítést kíván. Az egyik az ütemezett feladatok futtatásakor keletkező, a szervereinket érintő terhelésből fakadó teljesítményromlás. Ezeket a terhelési kiugrásokat üzemeltetési oldalon, a szerverparaméterek hangolásával, és a feladatok ütemezésének módosításával sikerült ellapítanunk.

A másik lassulásként jelentkező probléma üzleti szempontból sokkal kínosabb volt. Mindig azoktól a felhasználóktól érkezett ez a visszajelzés, akik a legtöbb adatot töltötték fel, akiknek a legrészletesebb profiljuk volt. Tehát épp az üzleti szempontból legértékesebb felhasználóinknál sérült a felhasználói élmény. Közelebbről megnézve ezeket a profilokat kiderült, hogy nem csak az a probléma, hogy lassan tölt be a profilszerkesztő, hanem a mentési folyamat is lassú.

Mérjünk

Mivel végre képesek voltunk reprodukálni a jelenséget, fel tudtunk tenni olyan kérdéseket, melyek mentén megtalálhattuk a probléma gyökerét. Az első gondolat az volt, hogy lassú az adatbázis, lassan épül fel a profil objektum. Nézzük meg az indexeket a field táblákon! Nem nyert. Bőven az előzetesen kiszabott időkorlát alatt volt, még a sok adattal rendelkező elemek betöltése is. De még az 1000 véletlenszerűen kiválasztott elem betöltése is 2-3 másodperc alatt megállt.

A következő tipp az volt, hogy ez mégis csak egy bonyolult űrlap, sok-sok mezővel és értékkel. Bizonyára ennek a felépítése tart sokáig. Legnagyobb meglepetésünkre ez is a korábbi feltételezett idő töredékét tette ki.

Ezután már tényleg nem volt más magyarázat, minthogy, mégis csak a böngésző számára küldendő HTML előállításával megy el az idő nagy része. A mérések pedig igazolták, hogy az említett sok adatos felhasználó esetén, a kattintástól kb 1 másodperc, míg minden adatot összeszed a szerver és felépíti az űrlapot. A maradék 25-55 másodperc pedig a kimenet előállítása. Aztán erre még jött a hálózati kommunikációval eltelő idő, plusz míg a böngésző megjelenítette az oldalt a sok képpel és egyéb, a használathoz szükséges kódok lefuttatásával.

Mire mennyi idő megy el?

User load < 1 sec
Form build 1.5 sec
HTML render 25 - 50 sec
Hálózati forgalom < 1 sec
Browser DOM + JS 1 - 5 sec

 

Nagyjából ekkor érkezett Andrástól az ötlet, hogy legyen automatikus mentés és plusz még 3 új mező. Az már ekkor látszott, hogy az új mezőket még meg tudjuk oldani, azonban a mentés automatikus indítása nagyon gyorsan a szerver túlterheléséhez vezetne.

Lehetőségek

A mérések alapján az elég egyértelműen látszott, hogy a Drupal biztosította keretek között ezt a problémát nem tudjuk kezelni.

Az volt a feltételezés, hogy a Drupal field kezelését megtartva tudunk olyan gépileg olvasható kimenetet előállítani, ami leírja az űrlap szerkezetét. Ezt a struktúrát használva pedig tudunk valamilyen kliens oldali technológiával építeni egy webapp-ot, amit majd a felhasználók használnak. Tehát a szerveroldali, teljesítményproblémákkal küszködő alrendszert kikötnénk, és egy kliensoldali megoldással helyettesítenénk.

Az ötletek összeírása után körvonalazódott egy rendszer, ami

  • a jelenleginél sokkal kevesebb adatot mozgat a szerver és a kliens között

  • emiatt gyorsabban töltődik be

  • gyorsabban tudja menteni a változtatásokat

Végeredményben egy sokkal jobb, pattogósabb szerkesztési élményt biztosítana a felhasználóknak.

Szerver oldali fejlesztések

Az új működési logika szerint a szerveroldali alkalmazásnak már csak négy tényezőért kellett felelnie. Információt kellett szolgáltatnia az űrlap felépítéséről, a szerkesztett profilról, kezelni a fájlok feltöltését és a profilmódosítások mentését. Az első két feladatot nem tudtuk az eredetileg elképzelt, egyszerű módon megoldani, de még így is nagyon gyorsan sikerült összerakni.

A módosítások mentése már bonyolultabb volt. Először a Drupal által biztosított eszközökkel szerettük volna megoldani, hogy ne kelljen bonyolult ellenőrző mechanizmusokat újraimplementálnunk. Mivel ezzel a megközelítés nem működött, a kényszerből lehetőség lett: a mentési folyamaton is optimalizálhattunk.

Kliensoldali fejlesztés

A kliensoldali technológiák fejlődési üteme az utóbbi pár évben rendkívüli módon felgyorsult. A felületes szemlélő csak annyit érzékel, hogy minden hónapban kijön a következő világmegváltó projekt, mindenki írja a saját keretrendszerét. Rengeteg kisebb-nagyobb csomag, kiegészítő és projekt van a piacon. Ezek között nagyon nehéz objektív szempontok alapján választani. Mivel András számára mindegy volt, így figyelembe vehettük azt is, hogy nekünk mi szimpatikus, mi lesz kényelmes.

Kézenfekvő választás lett volna a Drupal által is használt jQuery, amit megtámogathattunk volna jó pár kiegészítővel. Bár az eseménykezelés és a pluginrendszer már sokat bizonyított az elmúlt évtizedben, úgy éreztük, nem tanulnánk vele, és kihagynánk a lehetőséget az önképzésre és az új dolgok kipróbálására.

Tibinek volt tapasztalata az Angular rendszer első verziójával. De nem igazán szerette, nem volt kényelmes, és már nem is támogatott. Az Angular 2, csak a nevében hasonlít az első verzióra, míg az aktuális 4-es verzió már jelentős technológiaváltás lett volna. Az ezekkel járó kockázatok viszont már nem fértek bele a projekt kereteibe.

A végén az aktuális szupersztár, a React és az új, feltörekvő rendszer, a Vue.js maradt. E kettő közül kellett választanunk. Végignéztünk rengeteg példakódot, nyíltforráskódú megoldást, amivel felmérhettük, hogy valós feladatokat hogyan lehet megoldani ezekkel. Mérlegeltük a licenszek által támasztott használati feltételeket és a köré épült közösséget, de nem tudtunk dönteni. Végül elhangzott a kérdés, hogy “Fél év múlva melyikhez nyúlnál szívesebben?” Erre egyértelmű válasz volt a Vue, szóval ezzel álltunk neki.

Az eredmény

Amikor elkészültünk, minden elvárásunk teljesült. Az átlagos felhasználóknál kattintástól a szerkesztés megkezdéséig eltelő idő a tizedére, a szervertől a klienshez küldött adat mennyisége a felére esett vissza. A teljes szerkesztési folyamat alatt a szerverekre mért terhelés is látványosan visszaesett.

 

Az alábbi prezentációban ezt a folyamatot mutattam be:
http://slides.com/tikaszvince/speakerhub-com-user-editor