INSANE v2

Innen: iNSANE
A lap korábbi változatát látod, amilyen TheDoctor (vitalap | szerkesztései) 2017. január 30., 10:35-kor történt szerkesztése után volt.
Ugrás a navigációhoz Ugrás a kereséshez

Mi az a v2?

A v2 egy teljesen újraírt motor az insane alá. Ez azt jelenti, hogy a backend és a frontend teljesen nulláról van újraírva az új kor technológiáinak megfelelően. Az esetlegesen újrafelhasznált kódok teljesen át lettek nézve sorról sorra és ahol kellett javítva lett.

Az újraírás folyamán az elsődleges szempont a sebességoptimalizálás. Ebből kifolyólag bizonyos kompromisszumokat meg kellett kötni. Ezekről részletesen lejjebb lehet olvasni.

További cél volt a jó skálázhatóság is és a gyors fejleszthetőség is, az ismert modern technológiák minél jobb kihasználásával együtt (MVW pattern, frameworking, stb.).

A v2 koránt sincs kész, folyamatos fejlesztés alatt áll. Ez jelenti új funkciók bevezetését, valamint a már megírtak folyamatos modernizálását, karbantartását is.


A backend

A rendszer hátulja továbbra is php. Ennek több oka is van. Egyrészt a php nyelv sokat fejlődött az utóbbi időben, másrészt a backward compatibility miatt is szükség volt rá, harmadrészt pedig ehhez a nyelvhez volt kellő szaktudás.

Backward compatibility

Mivel a motor teljes újraírása óriási munka, úgy döntöttünk, hogy bizonyos elkészült elemeket a már futó rendszerben is használni akarunk. Egyrészt tesztelési, másrészt modernizálási célokkal. Emiatt a már futó rendszer mögött is sok helyen a v2-es modulok tudnak futni. Ennek viszont olyan ára volt, hogy a futó rendszerrel is kompatibilisnek kellett lennie a rendszernek. Ez némi kompromisszummal járt ugyan, de megoldható volt. Persze emiatt a futó rendszerhez is sok helyen hozzá kellett nyúlni, a korábbi xbt-s kódnak már csak töredéke van jelen a rendszerben, az is inkább csak a frontenden.

PHP

A kód 5.3-as php verzióban kezdett íródni, de az idők folyamán az újabb verziók megjelenésével azokkal is kompatibilis módon folytattuk a fejlesztést, PHP 7.0-ával is futtatható, deprecated funkciók sehol sincsenek használva.

A teljes kód objektumorientált, bizonyos megkötésekkel megfelelő design patterneket is használtunk, de a backward comptibility miatt nincs például namespacing, de ettől még teljes értékűen MVW alapokon íródik a dolog.

Design

A korábbi torrent motorokkal ellentétben cél volt egy jól fejleszthető, skálázható, tesztelhető rendszer megírása. Hasonló irányt vett a whatcd-s Gazelle is egyébként, bár ott más megoldások születtek. Patternként leginkább a MVW rendszer áll legközelebb az insane v2 motorhoz. A view teljesen szeparált (template-elhető), vékony controller réteggel és heavy Model réteggel megtámogatva. Ennek segítségével nagyon gyorsan fejleszthető. Például egy bookmarking rendszer hozzáadása 1-1,5 óra volt, aminek java része a view megírása volt.

Mivel nagyon sok interakció van az oldalon, a controller réteg ketté lett választva és kapott egy auto evaluation réteget is, így a formok kezelése is villámgyors és biztonságos és igen jól skálázható.

Framework/nem Framework

A v2-es motor felfogható framework-ként, mivel minden általánosan lett megírva és controller rendszeren keresztül van csak példányosítva (API-zható is). Ugyanakkor, mivel cél volt a sebességoptimalizálás, bizonyos helyeken eltértünk az általános framework szabályoktól. A v2 nem készül más oldalak számára, és a fejlesztése sem nyílt. Ebből kifolyólag néhány helyen megengedtük azt a luxust, hogy speciális insane specifikus kódok legyenek a model rétegben is. Ezzel megspórolhatjuk, hogy rettenetes objektumhierarchiák keletkezzenek minden futásnál. Továbbá nem keletkezett irtózatos osztálymennyiség sem, így nincsenek interface-ek és factory-k sem, de nincs is rá szükség. Ez futásidő szempontból a nagy lekérésmennyiség miatt erősen memória és processzorkímélő megoldásnak bizonyult. Csak összehasonlításképp a korábbi xbt-s oldal generálást néhol sikerült a tizedére csökkenteni.

Adatbázis

A backward compatibility és a korábbi rendszerrel való párhuzamos futás miatt az adatbázis ugyanaz maradt, mint a korábbi, azaz egy MariaDB fork. MySQLi kompatibilitással. Erre a modern php direktívák miatt is szükség volt.

Egyébként emiatt a v1-et is teljesen ezekre az alapokra helyeztük már korábban, nincsenek a kódban mysql_query-k sehol.

Adatbázis design

Sokáig hezitáltunk az InnoDB és MyISAM motorok közt, végül mégiscsak MyISAM-nál maradtunk. Egyrészt sebesség optimalizációs szempontok miatt, másrészt akkor még az InnoDB nem támogatta a FULLTEXT search-öt (azóta már igen). Így sajnos elvesztettünk pár nagyon kényelmes és hasznos funkciót, mint például az idegen kulcs kezelést vagy a rollbackinget, de a MyISAM pont arra van optimálva, amit az oldal működését is jellemzi, azaz rengeteg olvasás (select hegyek) és kevesebb írás. A szakirodalom szerint a MyISAM akár 15%-kal is gyorsabb lehet ilyen esetekben. Persze ez extra effortot jelent php oldalon, de kezelhető mennyiséget.

Adatbázis használat

Kód szinten a php csak egy saját, speciális csatolón keresztül kommunikál az adatbázissal, ezért adatbázis csatlakozás, valós adatbázis műveletek csak egyetlen ponton vannak a rendszerben. Ennek eredményeképp az adatbázis nagyon rövid időn belül lecserélhető a rendszer mögött - és persze a kód sincs tele mysql_query-kkel. A csatoló kapott pár hasznos funkciót, így nagyon könnyű lekéréseket végezni bárhol a rendszerben. Természetesen amit lehet, kivezettünk user cache-be, hogy kíméljük az adabázist és csökkentsük az egyidejű kapcsolatok számát.

Caching

Mivel a modern PHP-s rendszerek megoldják az opcode cachinget beépítve, ezért ezzel nem kellett már külön foglalkozni. Ugyanakkor a korábbi user caching rendszereket (APC) már nem lehet használni. Egyelőre az oldal mögött APCu fut. Ez ugyan elosztott rendszerekhez nem alkalmas, de az insane még nem hízta ki az egyszerveres kiszolgálást, így megtartjuk addig, amíg fejlesztik és nem kell több szerverre költözni. Ha ez megtörténik átállunk egy elosztott caching rendszerre (memcache, Xcache, eAccelerator). User cacheben tárolunk mindent, amit csak lehet; fordításokat, kategória táblázatokat, és rengeteg minden mást is természetesen. A cache pucolás mindenhol optimálisan be van építve, ahol szükséges, így nincsenek beragadt adatok.


Frontend

Többnyelvűsítés

Mobil applikáció

A mobil böngészők rohamos fejlődése mellett megszűnt az az igény, hogy külön mobil applikációt készítsünk, így ez nincs is tervben. Az oldal webes megjelenítését igyekszünk majd mobilra is optimalizálni.