Platformválasztás nagy terheltségű alkalmazáshoz
Sziasztok!
Segítségét kérném azoknak, akiknek volt már dolguk olyan weboldalt fejleszteni, aminek aztán nagy lett a terheltsége.
Sok weblapot csináltam már, elsősorban PHPben és ASP.NET-ben. Tapasztalatom van Pylons-szal és JSF-el is, annyi nem, hogy az életrajzomba írjam :)
Most kezdek bele egy weblapba, aminek várhatóan egész nagy terheltsége le (ha bejön, persze).
Nekem két lehetőség jut eszembe platformra:
CakePHP
JSF + Glassfish + TopLink
Mindkettő MySQL-lel.
Persze a rapid development is fontos szempont a választásban. :)
Kérlek segítsetek abban, hogy mennyire skálázhatóak ezek a technológiák nagy terheltség esetén, melyiket érdemes választani. Illetve volt már tapasztalatotok azzal, hogy a CakePHP template cache-elése mennyire gyors és használható? Érdemes-e a Cake-et összegyúrni Smarty-val? Mi a szűk kereszmetszet egy JSF alapú alkalmazásnál?
Összességében: Melyiket érdemes választani?
Ezer köszi!
zottty
■ Segítségét kérném azoknak, akiknek volt már dolguk olyan weboldalt fejleszteni, aminek aztán nagy lett a terheltsége.
Sok weblapot csináltam már, elsősorban PHPben és ASP.NET-ben. Tapasztalatom van Pylons-szal és JSF-el is, annyi nem, hogy az életrajzomba írjam :)
Most kezdek bele egy weblapba, aminek várhatóan egész nagy terheltsége le (ha bejön, persze).
Nekem két lehetőség jut eszembe platformra:
CakePHP
JSF + Glassfish + TopLink
Mindkettő MySQL-lel.
Persze a rapid development is fontos szempont a választásban. :)
Kérlek segítsetek abban, hogy mennyire skálázhatóak ezek a technológiák nagy terheltség esetén, melyiket érdemes választani. Illetve volt már tapasztalatotok azzal, hogy a CakePHP template cache-elése mennyire gyors és használható? Érdemes-e a Cake-et összegyúrni Smarty-val? Mi a szűk kereszmetszet egy JSF alapú alkalmazásnál?
Összességében: Melyiket érdemes választani?
Ezer köszi!
zottty
CakePHP NO
Egyébként lehet PHP-ban írni nagyteljesítményű horizontálisan skálázott webalkalmazásokat, csak jónéhány trükköt ismerni kell. Ez nem keretrendszerfüggő(mivelhogy az ismert PHP keretrendszerek le se sz*rják a horizontális skálázást, kivéve talán Drupal).
Másrészt pedig a Java területen nem lesz komolyabb gondod a skálázással, ellenben nem biztos hogy jól jársz ha nem fejlesztettél sokat eleddig Java/J2EE környezetben. Ha mégis ez irányt választod, mindenképpen fontold meg a GWT-t. Sok funkció kihelyezhető vele kliensoldalra. Mi írtunk már "vastagklienst" böngészőbe GWT-vel és egész jó lett.
Nyilván fogsz használni valami MVC keretrendszert itt is, hát én ajánlom a JBoss Seam-et, de kinek ugye mi esit kézre. Én személy szerint nem komálom a Struccot :)
Remélem sikerült támpontokat adnom.
framework kontra skálázhatóság
Üdv,
Felhő
Skálázás
Kétféle skálázási mód van. Ezeknek sikerült megszülni a horizontális és vertikális skálázás neveket.
A PHP vertikális skálázási lehetőségei sajnos a jelenleg elterjedt architektúrán az adott webalkalmazás példányainak növelésében merül ki. Ezen belül is komoly problémákat vet fel a szinkronizálás, mivel erre nincs kényelmes megoldás(file mutexek és hasonlók, amik kimondottan lassúak és problémásak, azok vannak).
Lásd például Java esetében lehetőséged van kényelmesen többszálon(tehát több individuális kérés között is) dolgozni, úgy hogy korrekt szinkronizálási lehetőségeid vannak.
Egy esetleges példaalkalmazás lehetne egy futtatókörnyezet szintű singleton, nem pedig PHP példány szintű. Egy Zend_Lucene-t nem szívesen tartok a memóriában sok példányban. :)
A horizontális skálázási lehetőségek pedig még rosszabb állapotban vannak. Operációs környezetek közötti szinkronitás vagy információs együttűködés pedig zéróminuszalfa, annyi sem. Nincs platformtámogatás cache koherenciára, tranzakciózásra. Ezeket a keretrendszerfejlesztőknek kell kiszenvedniük.
Lásd Java, ahol pedig a J2EE platformmal kapod ezeket készen, jól dokumentálva.
Éppen ezekért PHP alatt normális skálázást támogatni nagyon nehézkes. Ezért is foglalkoznak olyan kevesen ezzel, de az a kevés is csak akkor fog ilyenbe bele, ha pénzügyileg meg van finanszírozva (lásd Drupal clustering). Alapjáraton senkinek sem akaródzik ezt a témát kergetni.
A nagy PHP Web2.0-s szájtok esetében is problémák (voltak) ezek, de ott nyilván meg lettek fizetve emberek hogy ezeket áthidalják. Ezzel szembe kell nézni előbb vagy utóbb a nyílt forráskódú PHP-s közönségnek is, ha továbbra is erősödik a PHP helyzete a "komoly" platformok ranglétráján.
Összefoglalva, a platform alapvetően az oka hogy nehézkes skálázni. Nem hiszem hogy mondjuk a Java jobb választás lenne, mert ott teljesen más dolgok fogják megnehezíteni az életed. Sajnos nincs tökéletes választás jól skálázható platform ügyében (főleg hogy ennek komoly gazdasági megfontolások is megbújhatnak a hátterében).
Remélem sikerült legalább alapjaiban bemutaton az álláspontomat.
értelek
Az más dolog, hogy esetleg nem adnak plusz eszközöket, és neked kell megoldani mondjuk egy sesson kezelést. Azt nem tudom, hogy ezekre mennyire lehet "dobozos" jó megoldást adni, nekem inkább az volt a tapasztalatom, hogy ezek a rendszerek többnyire egyediek, testreszabott megoldásokra van szükség.
A Java-s részekre érdemben nem tudok reagálni, mert csak felületes ismereteim vannak vele kapcsolatban. Nem látom át, hogy egynémely említett funkcióra mennyire lehet szükség az átlagos (már ha lehet ilyet mondani a nagyterhelésű rendszerek esetében) weboldalaknál. Ha lesz időm, akkor valamikor elmélyedek ebben a témában, mert igazán érdekes, hogy Java oldalon milyen megoldások vannak, kíváncsi lennék, hogy ezek a platform nyújtotta lehetőségek mennyire használhatóak.
Valami oka viszont csak lehet annak, hogy a legtöbb nagyobb weboldal mögött nem Java áll (félre ne érts, véletlenül sem olyan sztereotípiákra szeretnék utalni, miszerinte a Java lassú lenne), és nem hiszem, hogy csak anyagi, vagy képzettségbeli okai lennének, mert azért van ahol egyik sem probléma.
Üdv,
Felhő
értve lenni jó
Ebben nem kételkedtem, de gondoltam azokra is akiknek ez új lehet és meglelik a topicot.
A lehetőségek sosem zavartak :) De viccet félre. Nem a platform korlátai zavarnak(igen, elb*sztam az előző hozzászólásomban - az archtektúra zavar elsősorban, a platform hülyeségeivel együtt lehet élni), hanem az elterjedt (LAMP, I mean) architektúra limitációi. Itt van ugye az én heppem, a Quercus, találtam is egy uber-brutál tuning howto-t Drupalhoz multkor. Megosztanám. Lényegében a PHP Java Servlet fordító és a Terracotta JVM clusterező megoldás házasítása, plusz egy csipetnyi elosztott ehcache. Én kipróbáltam (igaz hogy nem resin-nel) és brutális 16x-18x növekedés figyelhető meg a kiszolgálás sebességében. Ennek az oka talán az Drupal RDBMS kezelése mögött bújik meg. Mivel minden memóriában van, amit használni szeretne, nem nehéz jól produkálni :) Ebből is látszik, hogy mennyit számít az architektúra. A platformot viszont nagyon kedvelem.
Én úgy hiszem, hogy nem. A "dobozos" megoldások okkal kerültek dobozba. Bármiféle fürtözést támogatni szoftveresen nem kis munka, ez - mint említettem - nem olyan téma, amibe Pistike belefog otthon. Éppen ezért a testreszabottnak hitt megoldások lépten nyomon hagynak cserben és olyankor nincs hova fordulnod, hiszen a platform nem támogatja, te meg egy home-brewed megoldással próbálkozol. (Most tényleg nem azért mert én Java fanboy vagyok, de) Javaban legalább az alkalmazásszerverek támogatják (tekintsük őket is frameworköknek, mert végsősoron azok is), így van rá support is. Támogatniuk kell, mert a J2EE speckó megköveteli. Ez jó dolog.
Ezzel kapcsolatban fogadd személyes ajánlásomat. Egy PHP-s fejlesztő iszonyat sokat profitálhat egy ilyen alámerülésből. A Java és J2EE ötletei nagyon jók csak néhol kicsit használhatatlan az API meg a nyelvi konstrukciók.
Na most beégtem :) Nem találom azt a cikket a drupal.org-on, amire gondoltam. Valamely cég, utána pedig a Google SOC adományozott pénzt a Drupal normális load-balancing meg adatbázis elosztottság megvalósítására. Valamint gondolom neked nem kell bemutatni a high performane group-ot :) Azért ott is főleg vén rókák tanyáznak és egy részük fizetett fejlesztő, még ha nem is azért fizetik hogy közvetlen Drupal-t fejlesszen.
Félre nem érts, én sohasem mondtam hogy PHP-t nem lehet skálázni. Pusztán meglehetősen nehézkes, nagy hiányossága ez a platformnak (amit a megfelelő architektúrán elegánsan ki lehet kerülni). Én magam is nagyon szeretem a PHP-t, vannak feladatok, amelyek egy-az-egyben PHP-nak valóak és vannak azok, amelyekre ezt az egész J2EE hóbelevancot kitalálták. Mindennek megvan a helye.
Másrészt úgy vélem elsősorban anyagi okai vannak annak hogy gyakoriak a LAMP startup-ok vagy webkettes népszerű oldalak. Az az igazság hogy PHP-ban gyorsabban fejlesztesz, áttekinthetőbb a munka, és általában kevesebbet kell szívni vele. Míg a hardver olcsó, a munkaerő nem az. A PHP-s munkaerő pedig a világon mindenhol olcsó és igen bő a kínálat is belőle. Olyan pedig nincs hogy pénz van bőven. Lehet hogy van most, de jövőre miből lesz?
Végezetül álljon itt egy blog és arra válasz. Nem mindenben értek egyet az urakkal, de lényegében megfogalmazzák a dolgot:
Why Are Most Large-Scale Web Sites Not Written in Java? (Bocs a jump-through linkért)
Ui.: ...és az ajándék link drupal scalinghoz, mint érdekesség és hasznosság :)
GWT
Bár nem tudom mi van mögötte, de pl gmail és eredeti google alkalmazások mögött AFAIK igenis JAVA (GWT) áll.
Annyira evidens
Ettől függetlenül például a RedHat Mugshot-ja is Java Servlet alapú.
iwiw architektúra
Üdv,
Felhő
iwiw üzenetek
Azaz a logika kb:
1. kirajzolom a menüt (itt még van olvasatlan üzenetem)
2. kiveszem az üzenetet dbből, megjelölöm olvasottként
3. kiiratom az üzenetet.
Ez alapján lehet következtetni a site megoldásaira...nekem nem nyerte el a tetszésem.
iwiw...
Re
Másrészt pedig elkovetik a hibákat újra és újra. Foltozzák a vékony műanyagzacskót. :)
CakePHP
Gyors és használható. (És rapid...)
Nem.
Köszi
Én egy nagyobb terheltségű alkalmazást készítettem, PHP/MySQL-ben, saját frameworkkel (akkor még nem voltak divatosak a ready-to-use frameworkok :) ) és persze nagy terheltségnél felfutott a terhelés, igencsak. Erről volt is egy témám itt a weblaboron.
Végül már mindent leoptimalizáltunk, SQL hívások, adatbázis, PHP előfordító a háttérben, autoloader kiszedve, már tényleg a leg idiótább dolgokat optimalizáltuk, amivel sikerült kb 20%-os sebességnövekedést elérni. Aztán a végére kiderült, hogy a template rendszer húzza vissza az egészet. Nagyobb koncepcionális hiba nem volt a tervezésében, de nem cache-elt. Miután sikerült megcache-eltetni, iszonyat sebességjavulást értünk el.
Még egy PHP-s kérdés, ami ide kapcsolódik:
Ha nagy terheltség, akkor CAKE, vagy Symphony? Ez utóbbit egyáltalán nem ismerem.
(P.s. facebook.com php/mysql comboval megy, szóval az biztos, hogy a skákázhatóság jól megoldható, kérdés milyen áron :) )
Eldönthetetlen
Erre sosem fogsz normális választ kapni. Ajánlom hogy nézd meg, próbáld ki mindkettőt és dönts te magad. Mi nem ismerjük a döntési szempontjaid finomságait, csak annyit hogy nagy terheltségű webalkalmazás készítéséhez szeretnéd használni és fontos a teljesítmény. Ez alapján a helyes válasz az lenne, hogy egyik sem :)
Ui.: Ha nem ismered a Symfony-t, itt egy cikk a weblaboron róla.
De ők nem is használnak ready-made keretrendszert ;)
yahoo bookmarks
Kicsit elcsépelt ugyan, de pl. a yahoo bookmarks symfonyt használ, mondjuk érdekesek a legfőbb kiválasztási szempontok: http://www.symfony-project.com/blog//2006/10/28/yahoo-bookmarks-uses-symfony.
Üdv,
Felhő
Plusz