Segítség, belassultunk! – 1. rész

Vince

2015. december 15. átlagosan indult. Hétkor felvettem a kulcsot a portán, felsétáltam a másodikra. A reggeli kávé mellett egy továbbított levél olvasása után azon gondolkodtam, hogy vajon tényleg hajlandóak lesznek-e emberek kitölteni a harminc-negyven mezőt, hogy vonzónak tűnhessenek a rendezvényszervezők szemében.

Ebben a projektben az előadó a portéka. A speakerhub.com az a hely, ahol rendezvényszervezők kereshetik a következő konferencia előadóit. Ezzel az ötlettel keresett meg bennünket András 2015 nyarán. Az alap funkció az, hogy az előadók feltöltik és szerkesztik a profiljukat. Az adataik alapján jelennek meg a keresőben, ahol az érdeklődők megtalálhatják őket. Tehát ennek a funkciónak a megbízható, stabil működése az egyik legfontosabb szempontunk.

Gyors fejlesztés vs. skálázható megoldás

Drupalban gyorsan lehet prototipizálni. A nap végére összeraktuk a projekt alapjait. Ekkor már az előadók tíz féle adatot tudtak megadni magukról. A nap végén működött a listázó és egy alap kereső is. Ez a gyors építkezés lehetővé tette, hogy András szerteágazó ötleteire gyorsan találjunk válaszokat. Egy fél éves munka alatt összeállt az a rendszer, ami a mai napig is a gerincét adja az alkalmazásnak.

A rendszer élesbe állásakor egy felhasználó 45 mezőt használva építhette fel a profilját. A fejlesztés nem állt meg. További funkciókat adtunk a projekthez. Ezek egy része a felhasználók adatfeltöltési lehetőségeit cizellálták tovább, mások a site értesítési rendszerét segítettek finomhangolni vagy olyan funkciók voltak, amik a szerkesztők munkáját tették könnyebbé. És persze volt egy nagy adag olyan fejlesztés is, ami a projekt gazdasági fenntarthatóságát hivatott szavatolni.

Ezt követően az első kérdésemre egyértelmű választ kaptam, amikor a célközönség elkezdte használni az oldalt, és tömegesen érkeztek az új regisztrációk. Egy év leforgása alatt olyan látogatottsági mutatóknak kellett megfelelnünk, ami komoly kihívások elé állította a rendszerünket. Ahogy nőtt a felhasználók száma, és híztak a profilok, úgy csökkentek a válaszidők. Tavaly nyáron a mezőink száma elérte a 120-at, ami sok-sok olyan problémát vezetett elő, aminek megoldását a korábbi módszereinkkel már nem tudtunk kezelni, és nem is halogathattuk tovább a megoldást.

Szerveroldali félelmek

Az egyik legmakacsabban visszatérő problémánk a lassúság volt. Több projektünk is van, ahol nagyságrendileg ennyi adatot vagy tartalmat vagy felhasználót kell kezelnünk. Olyannal is volt dolgunk, ahol ennyire részletesen kellett egy-egy dolgot leírni. Arra is volt példa, hogy egy mező értéke akár 200 értéket is tárolhat. Ezeknek a kezelésére vannak kipróbált módszereink. Hol egy kis átszervezés, hol a szerverkörnyezet paramétereinek finomhangolása a megoldás. Ebben az esetben viszont egyszerre kellett kezelnünk ezeket a dolgokat. Ha az egyik problémát a megszokott módon kezeltük, akkor egy másik ponton további teljesítményromlást tapasztaltunk, vagy a stabilitást kockáztattuk.

Mivel a felhasználók és az ügyfelünk részéről is folyamatosan érkeztek a továbbfejlesztési ötletek és igények, mindig volt lehetőségünk úgy hozzátenni a projekthez, hogy egyúttal kiküszöböljünk korábban keletkező problémákat, és lehetőséget kaptunk, hogy megelőzzünk jövőben keletkezőket. De így is volt egy kérés, amire sokáig kénytelenek voltunk nemet mondani.

A felhasználók felől nézve a kért funkció a kényelmet szolgálta volna. Az ügyfél felől nézve az elégedett felhasználók az üzletnek jót tesznek. Fejlesztői oldalról sem tűnt egy nagyon bonyolult feladatnak. Viszont az üzemeltetési oldalról a teljes szerverkörnyezet stabilitását érintő félelmek fogalmazódtak meg.

Ekkor úgy éreztük, hogy maga az üzletileg alapfunkciónak számító profil szerkesztő felület is elérte azt a pontot, amikor már minden új funkció, minden jobbító szándék ellenére lassítani fogja az oldal használatát, végeredményben rontani fogja a felhasználói élményt. Mivel az nem volt opció, hogy nem tudunk több funkciót hozzátenni, körülnéztünk, milyen megoldása van a jelenlegi állapotnak.

Jeleztük Andrásnak, hogy eljött az idő, hogy az új funkciók implementálása helyett egy jól skálázható megoldást kell keresünk, amivel kiválthatjuk a Drupal által biztosított profilszerkesztőt.

Frontend plasztikai upgrade

Összeszedtük, hogy milyen akut problémáink vannak, megnéztük, mik voltak azok a korábbi kérések, amiket nem, vagy csak kompromisszumokat vállalva tudtunk megoldani. Ezeket használtuk egy új igény csokorként. Ezután felírtuk a saját szempontjainkat is: teljesítmény, fejleszthetőség, fenntarthatóság. A következő lépésként megpróbáltuk megérteni, hogy az aktuális állapot mely pontokon nem felel meg ennek az új követelményrendszernek. Van-e lehetőség kicsi ráfordítással érdemben legalább egy ponton javítani, vagy radikálisan kell hozzányúlnunk a projekthez.

A mérések és elméletek ellenőrzése után végül a radikális beavatkozás tűnt a hosszabb távon is járható útnak, ezért a fenti igényeket egy technikai követelményrendszerbe foglaltuk. Meghatároztuk a célt, és hogy milyen lépések mentén fogjuk elérni. Mivel technológiai értelemben egy új területre léptünk, egy kísérleti projekttel kicsiben ellenőriztük, hogy a kitalált megoldás működhet-e egyáltalán. Megmutattuk a megrendelőnek, aki bólintott, és elkezdődött az érdemi munka.

A második részben részletezem, hogy milyen milyen megoldások merültek fel, és végül mi mellett tettük le a voksunkat.

Az alábbi prezentációban ezt a folyamatot mutattam be: