Az appengine alkalmazás fejlesztésének és üzemeltetésének van egy elég egyszerű szabálya: maradj minél távolabb a kvóta limitektől. De a kvóta limitek mellett létezik még néhány íratlan szabály, amire nem árt figyelni. Vannak a felhőszolgáltatás jellegéből adódó tévhitek, amik közül most kettőt kivesézek.
"Végtelen sok memória van." Ez egyrészt nem igaz, mert jól meghatározott keret áll az alkalmazások rendelkezésére. Ha egy alkalmazás belerúg egy nagyot a memóriaplafonba és a GC futtatás nem szabadít fel elég memóriát, akkor egy jóval drasztikusabb szemétgyűjtő módszer kerül bevetésre: leáll az alkalmazás. Másrészt a java elég hatékonyan tudja elhasználni a szabad memóriát, főleg ha az összes menő keretrendszert beletesszük a szoftverbe és nem figyelünk rá hogy milyen adatokat hogyan tárolunk. Az appengine ebből a szempontból nem úgy viselkedik mint egy átlagos webszerver. Nem kezd el vergődeni, hanem simán kinyírja a szervletet ha valami gond van. Ha rosszul van felépítve a kérés kiszolgálás, akkor minden egyes alkalommal kinyírja, mellesleg ez már nem is elhanyagolható összegbe kerül, ha esetleg a kvóta limitek fölött vagyunk.
"Nem számít az indulási idő, mert lehet venni dedikált példányokat." Az alkalmazások terhelés hiányában időnként (tapasztalat: kb. 2 perc múlva) maguk is leállnak, így amikor a következő felhasználói kérés bejön, el kell indulnia egy alkalmazás példánynak és a felhasználó találkozni fog az indulási idővel. Ha pedig ez fél perc, akkor ennyi idő alatt jön le a válasz, ennyi idő amíg bejön a weboldal. Valóban lehet vásárolni olyan funkciót hogy állandóan fut N darab dedikált alkalmazáspéldány (N*1.2USD/nap). Ez szimptomatikusan megoldja a problémát, de valójában semmi sem garantálja, hogy a júzerek már egyáltalán nem fognak találkozni hosszú válaszidőkkel. Új alkalmazáspéldány akkor is indulhat, ha hirtelen megemelkedik a terhelés és nem elég az N dedikált példány. Másrészt pedig marad egy nyitott kérdés, mégpedig hogy mi történik abban az időben, amíg az indulás tart. Valószínűleg az történik, hogy jó sok pszeudó-szükséges dolog betöltődik a memóriába és kapásból közelebb kerülünk a memóriaplafonhoz, valamilyen formában bonyolultabb lesz a kérések kiszolgálása, több CPU idő fogy. Ez pedig azt eredményezi, hogy több példány tud kiszolgálni ugyanannyi terhelést, többe kerül az üzemeltetés. Emiatt bizonyos keretrendszereket, mint pl. a Spring vagy a Wicket nem túl szerencsés appengine környezetben használni. Csak alapos indok mellett szabad foglalkozni velük. Spring-et pl. tök fölösleges behozni, ha csak az IoC funkciójára van szükség. A JPA-val kapcsolatban sincsenek jó tapasztalataim. Nem szerencsés, amikor indulásnál elkezd XML-eket parszolni vagy reflection-nel osztályokat keresgélni, miközben a júzer vár a válaszra és ketyeg a taxióra.
A fentieket figyelembe véve legutóbb a 6 másodperces indulási időt sikerült 600 milliszekundumra csökkentenem, de még ezt is meg tudnám felezni. Ráadásul így dedikált példányok nélkül, cron-nal is meg lehet akadályozni hogy leálljon az alkalmazás, kvázi ingyen. Persze ez nincs benne a doksiban.
Az igaz, hogy egy alap appengine alkalmazást elég könnyen össze lehet dobálni, akár az SDK-hoz csatolt példákból evolválva, de ez csak a kezdet, ez még prototípus készítéséhez sem elég. Sokminden nincs még benne a doksikban és a mindenféle netes forrásokban, vagy éppen csak a sorok között van leírva. Sokmindent tapasztalatok útján kell megtanulni, a tapasztalat pedig csak a rászánt idővel gyűlik. Szerencsére nincs magas belépési küszöb, tehát könnyű elindulni, de szerintem kell egy év aktív fejlesztés, amíg az ember tényleg magabiztosan tud hatékonyan skálázható szoftvert írni appengine-re.
Apropó, tudtok olyan helyet ahova appengine fejlesztőt keresnek és engem is érdekelhet?
