ugrás a tartalomhoz

Meglévő framework használata vagy saját megoldás a teljesítményt figyelembe véve

Max Logan · 2007. Júl. 4. (Sze), 14.18
A nemrég indított Template engine topicban kialakult egy kis beszélgetés a framework-ökről. Felhő említette többször, hogy adott esetben a terhelés csökkentése miatt nem célszerű komolyabb framework-öt használni az adott alkalmazásnál, legalábbis nem mindent azzal megoldani.

Tanulságos volt a Template engine topic, amit indítottam, mert kicsit más szemszögből is nézem már a dolgokat. Eldöntöttem, hogy nyitok a komolyabb template engine-ek felé és úgy döntöttem, hogy megismerkedem pl. a CakePHP-vel.

A kérdésem az lenne, hogy egy olyan alkalmazás fejlesztésénél ahol elég fontos a teljesítmény, a skálázhatóség, érdemes-e mondjuk CakePHP-t választani framework-nek vagy inkább egy saját (MVC) megoldást érdemes alkalmazni?

Jelenleg teljesen saját megoldások alapján működik a rendszer lelke. Úgy próbálom felépíteni a kódot, hogy ne legyenek a jövőben teljesítmény gondok. Mivel több dolog van, ami miatt kénytelen vagyok jobban odafigyelni a terhelés kérdésre, ezért is érdekelne, hogy egy folyamatosan növő rendszert érdemes-e pl. CakePHP-vel felépíteni.

Ha már framework, akkor képbe kerül a JS is, mert a következő nagyobb fejlesztés az lesz, hogy AJAX alapokra lesz átültetve a rendszer. Itt jön a kérdés, hogy pl. prototype.js-t használjak vagy inkább saját JS és AJAX megoldásokat?
 
1

JS

zila · 2007. Júl. 4. (Sze), 15.48
Én a Symfony-t választottam keretrendszeremnek, így a CakePHP-hoz nem tudok hozzászólni (symfony-t is csak tanulom jelenleg, illetve egy pilot készül benne, ahol a terhelés elenyésző...)

Javascriptre a prototype nagyon jó, és érdemes megnézni az ext.js-t is.
2

nagy terhelés is relatív

Hodicska Gergely · 2007. Júl. 4. (Sze), 20.26
Felhő említette többször, hogy adott esetben a terhelés csökkentése miatt nem célszerű komolyabb framework-öt használni az adott alkalmazásnál
Kicsit furára sikeredett ez a mondat, de értem, hogy mire gondolsz. Igazán jó tanácsot ebben szerintem nem lehet adni, adott esetben kell mérlegelned, érdemes lehet tesztelned. Amiket felvetettem, azok elég speciáis esetek, több 10 millió oldal letöltés per nap (ráadásul nem egyenletes eloszlásban), de ez ritka. Ráadásul a terhelés nagyon nagy százalékát pár oldal adja ki, ezekre kell nagyon odafigyelni, a többi esetben lehetnénk kicsit pazarlóbbak.

A kérdésem az lenne, hogy egy olyan alkalmazás fejlesztésénél ahol elég fontos a teljesítmény, a skálázhatóség, érdemes-e mondjuk CakePHP-t választani framework-nek vagy inkább egy saját (MVC) megoldást érdemes alkalmazni?
Alap esetben tuti nem mondanám, hogy saját cuccot állj neki használni. Alapvetően teljesen igaz amit Fraki mondott, miszerint a legdrágább a fejlesztési idő. Plusz kb. mindenhol azt írják, hogy nincs rosszabb, mint a felesleges előre optimalizálás.

Amire nagyon figyelj oda, hogy skálázható megoldásokat használj. Ha ezt mindig szem előtt tartod, akkor a terhelés növekedését jó esetben könnyen tudod kezelni. Szintén fontos, hogy lehetőleg ne vigyél bele a program strukúrába felesleges kötéseket, minél jobban cserélhetőek legyenek a rendszer különböző komponensei. Alap példa: kezdetben nincs mondjuk szükséged cachelésre, de azért jó ha figylesz arra, hogy könnyen tud beépíteni a rendszerbe.

DB esetén is valami hasonlóra kell figyelni. Előre ne állj neki optimalizálni, használj rendes, normalizált struktúrát, aztán szülség esetén úgy is ki fog derülni, hogy mi a szúk keresztmetszet, aztán ott lehet valamlyen fajta denormalizálással, összesítő táblák létrehozásával stb. segíteni.

Ha már framework, akkor képbe kerül a JS is, mert a következő nagyobb fejlesztés az lesz, hogy AJAX alapokra lesz átültetve a rendszer. Itt jön a kérdés, hogy pl. prototype.js-t használjak vagy inkább saját JS és AJAX megoldásokat?
Ebben konkrét tapasztalatom nincs, de az biztos, hogy JS esetében valamilyen cuccra szükséged lesz, különben beleőszülsz a böngészők eltérő dolgainak kezelésébe.

Plusz egy valamily widget gyűjtemény az nagy áldás lehet (ext az nagy királyság), ugyanis még ha nem is bonyolult, de azért elég sokat el kéne bibelődni különböző elemek létrehozásával, meg például gondolom, hogy egy datagrid rendezésénél egy extbe quick sortot fognak használni, nem kell Neked ilyesmikkel szórakoznod. Meg mondjuk ha egy YUI elég a YAHOO oldalain, akkor az valszeg nem lesz Nálad sem szűk keresztmetszet. Szerintem (ha csak nem valami iszonyat komplex GUI-ról van szó) egy intenzívebb AJAX alkalmazás esetén is a backenddel lesz több problémád: rengeteg apró kérés, amit jó gyorsan kell kiszolgálni a felhasználói élmény bztosítása érdekében.


Üdv,
Felhő
3

mootools.net

Thoer · 2007. Júl. 4. (Sze), 21.51
PHP frameworkökben nem/sem vagyok annyira otthon, de ha gyors és jól használható javascript keretrendszert keresel, akkor szerintem néz körül a mootools-nál is. Nagyon gyors, szerintem megbízható, minden épkézláb böngészőt támogat és nagyon jó kis közösség van körülötte, akik az összes általánosan felmerülő problémát lezongorázták már. Igaz hogy nem feltétlen tud annyit mint az ext.js, de valahogy sokkal szimpibb, hogy azt rakok bele amit akarok, villámgyors és kicsi és nincs az ingyen után se az a csúnya 'de'... ;)
4

de?

amonrpg · 2007. Júl. 5. (Cs), 21.06
nincs az ingyen után se az a csúnya 'de'.

Miért, az Ext esetében milyen csúnya "de" van az ingyenes után?
LGPL licenszes. Azaz majdnem azt csinálsz vele, amit csak akarsz. Csak nem adhatod el, mint saját terméket. De azt hiszem, hogy ez amúgy is természetes.

Csak akkor kell business licenszet venned, ha támogatni akarod a srácokat, vagy ha prémium support-ra vágysz. Amúgy enélkül is elég hamar segítenek.

Amúgy lehet, hogy a mootools kicsi, és cute, viszont az Ext-ben olyan problémák vannak megoldva, kulcsrakészen odaadva a feneked alá, amikkel el leszel hónapokig, ha ki akarod újra fejleszteni. Lásd datagrid, sorrendezéssel, oszlop-menedzseléssel, stb.

Érdemes rá vetni egy pillantást. Én belehabarodtam. :D
5

Ext

Max Logan · 2007. Júl. 5. (Cs), 22.43
Ext-re már régebben rátaláltam, de akkor csak mint érdekesség tartottam számon. Most ahogy megnéztem a demo-kat kicsit részletesebben, valamint hogy milyen könnyen lehet előállítani, egyből beleszerettem. Azt hiszem megvan a céges rendszer továbbfejlesztéséhez a JS keretrendszer.

Bár a mootools tetszetős a demók alapján, az Ext pontosan olyan megoldásokat szolgáltat amire szükségem lesz.
6

Teljes felületekre

Fekete Ferenc GDA · 2007. Júl. 6. (P), 12.52
Az Ext tényleg jó akkor, ha "teljes" ajaxos felhasználói felületeket szeretnénk létrehozni. Szép default skin-ek, egységes megjelenés, hatékony layout kezelés, tehát "szinte" a desktopon megszokott felületeket tudjuk létrehozni, ráadásul nagyon gyorsan és többnyire szenvedésmentesen:) Ha megtanuljuk, mert azért elég sok mindent a fórumból kell kibogarászni, de legalább készséggel segítenek.

Egyszer írtunk is róla (itthon elsőként).

Mivel a topic címében a teljesítmény szó is benne van (bár az nem a javascript framework-ökre értendő, eléggé elkanyarodtunk) fontos megjegyezni, hogy az ext-el létrehozott felület betöltődése és működése nem feltétlenül a leggyorsabb, legalábbis saját tapasztalat szerint. (ajax-os tabos navigáció és layout kezelés, layouonként rendezhető grid-ek, xml adatforrással, lapozással, szerkesztéssel). Azt azért tegyük hozzá, hogy futott mellette egy-két erőforrásigényes cucc nálam.
7

Like desktop

Max Logan · 2007. Júl. 6. (P), 15.11
A rendszer amit fejlesztek egységsugarú user-eknek készül. Adott esetben egy excel táblázatot is hibásan töltenek ki, tehát az ext ilyen szempontból lenne hasznos, hogy legalább egy ismerős GUI fogadja őket.

Ami a betöltést illeti, ahogy néztem az ext-base és ext-all együtt 500KB, amit ezzel a megoldással kb. 130-150 kb-ra lehet tömöríteni, ez pedig nem vészes, ha azt nézzük, hogy az alap prototype.js ~100 KB.

Ahol lehet cache-elve lesznek az adatok, tehát a JS statikus adatokat kap. Jelenleg a legkisebb keresztmetszet a webszerver és az SAP szerver közötti sávszélesség.

A kérdés az, hogy ha ext.js-t használok, akkor érdemes-e mondjuk egy CakePHP-t használni szerver oldalon?

(Ps.: Annyira azért nem kanyarodtunk el, mert a JS framework is kérdés volt ...)
8

like desktop

Fekete Ferenc GDA · 2007. Júl. 6. (P), 15.49
Egy gyors javítás: A prototype 55K körül van most és ez nem a tömörített méret, simán át tudod nézni a függvényeket.

Persze ha kellenek mellé effektek, mint pl a scriptaculous, akkor már 100k-nál vagyunk, ahogy mondtad. Sőt, túl is léptük.

Az említett felületet mi egy rails alkalmazás adminjához készítettük el (ezért lehet érdekes neked a cakephp), jól működött, szép volt, stb, de rá kellett jönnünk, hogy amit a rails ajax helperei és template/partial kezelése miatt kényelmesebben tudunk dolgozni. Ezért aztán visszalakítottuk az egészet. Ezzel elvesztettük a pl. "vista look" layout-ot, és az ext-gridet, helyette csináltunk sajátot, nagyjából ugyanazt tudta, nem tartott semmiből. Jelentősen gyorsult az ui-n keresztül elvégezhető munka.

Ebből is látszik, hogy bizonyos esetekben jól jön, bizonyos esetekben nem. Jó tudni, hogy az ext kisebb komponenseit pl felhasználhatod, ha nncs szükséged az egészre: ilyen pl. a tab-os navigáció, ami klikelésre tesz láthatóvá div-eket és még a tabok is kapnak szép (browser független) layout-ot.
10

viszont akkor itt is megkérdem. :D

amonrpg · 2007. Júl. 6. (P), 18.53
Mikor lesz az Ext cikk folytatása? :D Ezt megkérdeztem az említett cikk alatt is... :)
11

when it's done

Fekete Ferenc GDA · 2007. Júl. 7. (Szo), 18.50
Hát erre egy kicsit várni kell, mivel mostanában ne mhasználjuk, de jelzem a munkatársam felé, hátha megírja a folytatást. Valószínűleg az (is) top post lenne a blogon, mint az első rész.
9

lassúság

amonrpg · 2007. Júl. 6. (P), 18.51
Nos igen, én éppen ezért szoktam válogatott Ext könyvtárral dolgozni (pl nincs szükségem az ablakozásra, ilyesmi), és egy fájlba másoltam a tömörített Ext-tet a Prototype-pal és a script.aculo effect könyvtárával.
(Mindegyik tömörített)

Sokat segít amúgy az, hogy ha nem muszáj, akkor nem bekapcsolt Firebug-gal nézed, ugyanis a legtöbb időt az viszi el, hogy a FB felparse-olja magának a JS fájlt. Azért valljuk be őszintén, az eléggé időigényes egy 200-300, esetenként full Ext kiszerelésnél 500k-nál.