Indul, vagy kimondhatjuk hogy már el is indult a zoom.hu portál, mely nem kisebb célt tűzött ki maga elé, mint az Index.hu és Origo.hu oldalakkal felvenni a hírversenyt. Úgy tudom hogy szép nagy szerkesztőséggel, nem kis (de nem is olyan nagy mint amiről eddig szó esett) pénzzel vágtak bele a dologba. Szerkesztőségi rendszernek Drupalt választottak, amit eddigi tapasztalataim és a magyar Drupalos/rendszergazdai ismereteket ismerve rossz választásnak tartok. Nem azért, mert a Drupal rossz lenne, hanem mert már a mostani indulásból is az látszik, hogy nem tudják hogyan kell üzemeltetni egy ekkora oldalt.
Drupal alapú portált üzemeltettem már jómagam is: a Weblabor és a Drupal.hu is volt már a szervereimen. A Weblabor magában kb. 5000 napi látogató kb. 10.000 oldalletöltésének a kiszolgálását jelentette. Kezdetben ez egy szerverrel volt megoldva, majd a későbbiekben két szerverre lett szétrobbantva a dolog (webszerver és adatbázisszerver), de összességében így is kb. 1 szervernyi erőforrást vitt el a kiszolgálás. A Zoom.hu az Index és az Origo nagyságrendű látogatottságot célozza meg, az Index esetén ez 850.000 látogatás 3.200.000 oldalletöltését, az Origo esetén pedig ennek kb. háromszorosát jelenti. Nagyon durva és buta egyszerűsítéssel ez 32-100 szervert jelent. Ezzel a számítással két gond van, az egyik hogy az alap Drupal kód amit látni lehet az oldal mögött az nem többszerveres környezetre van tervezve így nem skálázható automatikusan ilyen megoldásban, másrészt pedig hogy azért lehet optimalizálni a Drupal üzemeltetésén is, ha valaki ért hozzá. Így is nem kicsi pénzkidobásnak tűnik első ránézésre a dolog.
A hazai Drupal közösségben vannak olyan emberek, akik láttak már hasonló méretű oldalakat kiszolgáló szerver környezetet (hasonló a véleményük mint az enyém), jómagam is ismerem mind a Netvibes, mind pedig hazai vonalról például a Nemzeti Sport Online, vagy a Blikk oldalainak mögött levő architektúrát, illetve azokat a kódokat és megoldásokat, melyek az ilyen környezetekben életképesek tudnak lenni. A Drupal kódját ismerve egy az egyben biztosan nem alkalmas erre a működésre: üzemeltetési szinten nincsen tartalom publikálási folyamat, az újságírók az éles adatbázissal dolgoznak (nem az van, hogy megírják a cikket, majd az kikerül az éles szerverekre), a felhasználók sokáig be vannak léptetve és ez a működtetés nincsen különválasztva az oldal kiszolgálástól, ergo a belépett felhasználók számára a személyre szabott oldalt kell kitenni, továbbá alapból nincsen megoldás a statikus tartalmak külön erre optimalizált szervereken történő hosztolására (átszinkronizálására) sem. És számos ilyen jellegű kisebb-nagyobb probléma van a Drupal kódjával, melyekről tudom hogy megkerülhetőek, de azt is, hogy akik meg tudják kerülni, azok profi Drupal szakemberek (nem olyanok, mint én 
. A szép nagy látogatottságú Drupal.org vagy SpreadFirefox is Drupal alapokon fut – tehát a feladat semmiképpen sem lehetetlen, csak nem egyszerű. A felsorolt gondok közül pár megoldása nem lesz elegendő, egy jól használható rendszerhez még ezen problémák megoldásánál is több kell (van már szerkesztőségi tapasztalatom is Magyarország.hu és kisebb oldalak kapcsán).
A Zoom.hu üzemeltetői és fejlesztői több hibát is elkövettek, melyek azt mutatják számomra hogy a kellő üzemeltetési tapasztalattal nem rendelkeznek. Nagy hiba például a címlapra kihelyezett szavazás, mert ez azt jelenti, hogy a belépett, már szavazott felhasználóknak más tartalmat kell kiszolgálni, mint amit a nem belépett, vagy még nem szavazott felhasználóknak. Persze így is van cache a dolog mögött, de az ideális az lenne ha a címlapot boldog-boldogtalan mindenféle PHP közreműködés és testreszabás nélkül kapná meg. Kb. tizednyi architektúra kellene. Az olyan alapvető és statikus tartalmak kiszolgálására optimalizált szerverekért ordító dolgok, mint a JavaScript és CSS fájlok, logó kiszolgálása is a Drupal-t futtató szerverről van kiszolgálva, az oldalak tartalmának cache-elése teljességgel le van tiltva, arról nem is beszélve, hogy 17 CSS és 15 feletti JavaScript fájl töltődik le külön-külön, ami még ha már böngésző cache-ből szolgálódik is ki, kb. 30 felesleges, darabonként kb. tized/huszad másodpercnyi (összességében másodpercek!) extra várakozást és szerver terhelést jelent.
A design egyébként alapvetően nem rossz, de a logó még ha ötletes is, alapvető problémákkal küzd (a fejléc billeg a megemelt M betű miatt). A kategóriákat kiemelő túl hangsúlyos sávnak funkcionalitása nem nagyon van. A rovatoldalakon lehetne még bőven csiszolni, helypazarlóak és kiegyensúlyozatlanok. Van egyébként egy kis Indexes designbeli utánérzés, de az alap Drupal design is egész jó, így lehet, hogy ezek a design elemek részben onnan származnak.
A tartalom fő váza teljesen ígéretes, de például a kevésbé fővonalnak számító sport és IT/tudomány rovarok egyelőre nem túl erősek – ezeket illetően valamilyen erősítés nem ártana, ha tényleg az Index és Origo vonal a cél. A blogok bevonása az oldalba még nem tökéletes: a gond az hogy nagyon el lettek dugva az egyes blogok, és hogy nem képeznek különálló egészet. Szerencsésebb lenne egy önálló, erre a célra optimalizált blogrendszer használata, mely mind megjelenésükben elkülönítenék egy kicsit az oldaltól a blogokat, mind pedig jobban ki tudná szolgálni a blogoktól elvárt igényeket. Az Index nagyon-nagyon erős ezen a vonalon, és mivel úgy gondolom hogy ez egy hangsúlyos irány a jövőt illetően, ezért valószínűleg ezen is jó lenne változtatni, ha komolyan gondolja a főszerkesztő a dolgot.
Összefoglalva: az üzemeltetési/fejlesztési vonal szerintem fájdalmas és nagyon kátyús lesz, a tartalmi vonal az indulásnak megfelelő és jó irány lehet. Akarva-akaratlanul az az ember érzése, hogy a fejlesztői csoport nem volt jó választás, ekkora tőkével és célokkal illett volna egy erre méltó, ilyen jellegű referenciákkal rendelkező céget választani, mely már megtapasztalt ekkora látogatottságot és megoldott nagy rendelkezésre állást is.
A logó elég gyenge szerintem…
Mondhatjuk ugy is h. az ido rovidsege miatt ezt sikerult kihozni, a tartalom nem vesz el az alatta futo cuccokat meg at lehet gyurni ha ugy alakul vagy akar teljesen lecserelni, persze felteve ha szukseg lesz ra…!
Mondjuk, most hogy olvasgatom, tényleg jól áttekinthető a lap!
Néhány random vélemény és észrevétel:
– Nem tartom szerencsésnek a Weblaborral való összehasonlítást. A Weblabor kódja egy némileg hekkelt Drupal 4.6-os kód, azóta klasszisokat javult rengeteg dolog teljesítménye. Ezt a Weblabor.hu is megérezné, ha végre eljutnánk a frissítéséig. Egyébként a Weblaboron sincs semmiféle gyorstárazás, nem is csoda, hogy zabálja az erőforrást. Hoppá, hoppá. Azon a háztájon is lenne mit söprögetni, szerintem nem összehasonlítási alap, ismétlem.
– Ami a content staginget illeti, kiváló megoldások vannak erre, amiket midnenféle saját fejlesztésű szerkesztőségi rendszer is megirigyelhet, nem véletlenül látunk egyre több sajtóterméket Drupal alapokon. Például a New York Observer case study-ban szépen leírják a mikénteket, amiben akár komplett rovat oldal elrendezéseket lehet átszerkeszteni és időzíteni, megjelenés előtt természetesen. http://drupal.org/nyobserver magyarul: http://drupal.hu/cikkek/elektronikusujsag
– Van jopar kezenfekvo modul memcache, advcache, amiket terhelt webhelyeken jellemzően bevetnek. Ezek drasztikusan tudják javítani a webhely teljesítményét. Az egész skálázhatósági kérdés különben a klasszikus LAMP rétegek skálázásával menedzselhető mindenféle kód buhera nélkül is, de van CDN modul is, ha ki akarod adni a staikus content hosztingot valamilyen hálózatnak.
Ezek persze nem beépített dolgok, a Drupal ugye egy csomó legó elem, ha neked kis blog kell, akkor is kell hozzátenned az alap rendszerhez, ha pedig nagy hírújság kell, akkor is foglalkozni kell vele. Ehhez részben kell szakértelem, részben pedig természetesen idő és próbálgatás. Ráadásul kétségtelen, hogy a Drupal architektúrájában vannak olyan foltok, amiket a teljesítményre való tekintettel jobban is meg lehetne tenni, nem egy hibátlan darab, de cserébe rengeteg más okossággal kárpótol, és persze nagyon sok tapasztalat és dokumentáció gyűlt már össze Drupal skálázás kapcsán. Csak két gyorstipp, hogy legyenek konkrétabb infók is:
http://www.lullabot.com/articles/using-lighttpd-static-file-server
http://wimleers.com/article/improving-drupals-page-loading-performance
Goba: Az a kérdés, hogy ebből mit tudott és mit fog tudni megvalósítani a cég, aki bevállalta a feladatot. Félek, hogy jelenleg egy nagyon alap Drupal-t látunk, amit te 1 nap alatt összeraknál.
Köszönöm a véleményed, jó egy ilyen kiegészítés hogy kerekebb legyen a bejegyzés.
Lehet hogy láma észrevétel, de csodálkozom, hogy napi 5 ezer látogató és 10 ezer oldalletöltésnek nem volt elég egy szerver, még inkább hogy ketté kellett bontani. Jómagam egy napi 6-8 ezres látogatottságú és átlag 13 ezer oldaletöltéssel bíró mozis lap tulajdonosa vagyok, ami egy olyan szerveren vert szállást, amely kb. 10 másik weboldalt szolgál ki, és az oldal elérése így is teljesen gyors.
Szóval milyen gép is volt pontosan az a szerver? Szerintem a 32-100 gép túlzás, el sem hiszem, hogy pl. az Index ennyin üzemelne. Az iWiW állítólag 20 szerveres, de az meg a java meg a fejlesztők szervezetlensége miatt.
BTW ez az oldal tényleg több sebből vérzik. Az első, hogy 90%-ban lemásolták az aktuális index dizájnt… Hajj, azért követjük.
halló, miért kapom javascript error-t amikor kommentelni szeretnék?
Tufee és Goba: a Weblaboros mondanivalóm lehet hogy nem volt teljesen érthető, mert az leírtam, hogy az egyszerűsítés durva, de nem igazán fejtettem ki hogy miért gondolom így. Ahogy Goba is írja, nem egy agyonoptimalizált Drupalról volt szó, és azt sem írtam le, hogy ez kb. két éve, egy ha emlékeim jók, kb. 1 GHz-es szerveren volt, átlag vinyókkal. Ennél ma már lehet jobb szervert betolni, illetve lehet jobban optimalizálni is. (A kettébontás nem a Weblabor teljesítménye miatt volt.) Természetesen 32-100 gép túlzás lenne egy ilyen oldalhoz, azonban ha olyan erőforrás zabáló hibákat vétenek mint amik most is láthatóak az oldalon, akkor lehet, hogy reális is lehet.
A Weblabor optimalizálásával, annak ellenére hogy pár cache funkció ki volt kapcsolva, foglalkoztunk azért. Hozzáteszem, korántsem voltak azonban olyan eszközeink, mint amit most a zoom.hu-nak kötelező lenne használnia. Emlékeim szerint nagyságrendi optimalizálást nem tudtunk megoldani a kialakított megoldások miatt. Ezekkel végülis nem voltak gondok, mivel a szerver bírta a helyzetet, s gyors látogatóbeli növekedés pedig nem jött.
További szempont, hogy akkoriban kb. napi 1 bejegyzés termelődött, a Zoom.hu esetében pedig gondolom legalább 10-20 cikk és hír fog megszületni, nem beszélve a hozzászólások gyakoriságának várhatóan nagyobb számáról. Az összehasonlítás természetesen ezért sem volt szerencsés.
András, az Index és az [origo] látogatottsági adatait honnan vetted? Legközelebb azért ilyenkor vessél egy pillantást a Webauditra.
Másrészt nem látom mi abban a probléma, ha 32, esetleg 100 server kell alá? 2 milliárdos beruházásba talán belefér. 2006-ban még mindenki azon hápogott, hogy lehet, hogy az [origo] egy milliárdést megvette az iWiW-et, azért az alá is kellett 300 servert tenni … persze nyílván a két oldal látogatottságát és oldalletöltésit nem lehet összehasonlítani.
miles: Tegnap előtti Webaudit adatokat kerekítettem. Javíts ki konkrétumokkal, ha rossz számokat olvastam volna ki, szívesen veszem. Ami a szerverek számát illeti, részemről azért baj, mert ha nincsen rá szükség, akkor felesleges pénzkidobásnak tartom.
Longhand: nem tudom.
Én az Indexnél átlag {hétköznap és hétvége, 14. hét} 660.000 egyedi látogatót látok 15.500.000 oldalletöltéssel, az [origo] esetében pedig 1.200.000 UU-t, 31.000.000 PI-vel. Mindkét esetben beleszámítva az összes vertikális portált, kivételt képez a portfólióból az iWiW.
Még csak 5.7-esen fut, ha áttérnek 6-osra akkor gyorsulni fog: http://www.zoom.hu/CHANGELOG.txt
Amúgy hogy futhat a Weblabor Drupal 4.6 alatt, amikor a legrégebbi támogatott verzió az 5.7? Vagy ilyenkor ti foltozzátok be az időközben felbukkanó biztonsági réseket?
miles: Én most csak a szerkesztőségi rendszer által érintett oldalakra próbáltam meg koncentrálni, azokat az elemeket emeltem ki a statisztikából. Avagy nincsen benne az Inda és egyebek.
A weblabor.hu költöztetésekor nagyon izgultam, hogy fog muzsikálni alatta az új vas, mert az előzőn tényleg nagyon nagy terheléseket produkált. A para felesleges volt, mert a vas simán elviszi a weblabort. Sok optimalizálás azóta nem volt a site-on, átálláskor én csak a kódszínezés kliens oldalira cserélésére emlékszem. Ebben lehet, tévedek.
Mindenesetre a szerver vígan jut levegőhöz, van bőven tartalék:
És még mellette fut a hu.php.net tükör is, ráadásul most egyedül, a hu2.php.net épp el van tűnve.
Aha, wordpress nem szereti az img taget. Ez lett volna a kettőspont után, mint mellékelt ábra.
http://weblabor.hu/misc/weblabor-week.png
Megjegyzem, a webszerver konfigra is nagyon tudnak ügyelni a zoom-os üzemeltetők, ugyanis a www nélküli zoom.hu-ra még mindig a beharangozó oldal jön be. Először azt is hittem, bebuktak a kezdő terhelésbe és visszavették a statik oldalt…
Most olvastam végig a bejegyzést és a kommenteket, és lenne kérdésem:
A bejegyzésben felvázoltad, hogy a Drupal nem biztos, hogy jó választás nagy forgalmú webhely üzemeltetésére (bár a Critical Mass talán rácáfol erre), az érdekelne, hogy az erőforrás-igénye és teljesítménye mennyit javult a Drupal 6.x verziójában?
NeverGone: Nem a Drupal alkalmasságát tagadom, hanem azt hogy nagyon sokat kell vele dolgozni hogy alkalmas legyen egy ekkora szerkesztőség munkájának profi támogatására, magas rendelkezésreállás mellett. Szerintem egy nagy látogatottságú portálok üzemeltetésében már tapasztalatot szerzett, egy direkt erre a célra kialakított szerkesztőségi rendszerrel rendelkező céget kellett volna választani (több ilyen is van ma Magyarországon), nem pedig egy olyat, amelyik alapvető hibákat vét (képtelen beállítani a zoom.hu domaint, csak a http://www.zoom.hu megy?), s referenciái között nem találni (én nem találtam) semmilyen CMS üzemeltetésben szerzett tapasztalatot.
Úgy tudom hogy a Drupal 6-ban is vannak a teljesítményt növelő újdonságok – a konkrét teljesítmény növekedés a használt moduloktól, az oldal kialakításától függ valószínűleg.
Ki a Zoom.hu fejlesztője András? AZ oldalon nem látom.
Köszönöm a választ!
Most mar megy az oldal www előtag nélkül is. Fejlődnek.
(Én tegnap hallottam a zoom.hu-ról először egyik ismerősömtől. Akkor nálam csak a beharangozó jött be. Nem is értettem miért, mert a srácnál tök jól látszott minden. Most már tudom, hogy azért, mert én régi szokásomhoz híven nem írtam be azt, hogy http://www.zoom.hu, csak zoom.hu :O
Háát, kíváncsi vagyok…
Longhand: trilobita.hu
Lenne pár észrevételem ezzel a bejegyzéssel kapcsolatban.
“Nemzeti Sport Online, vagy a Blikk”,
Azért mert a Publishingnél annó ezt a megoldást találták ki, ez messze nem etalon, és szerintem ma már nem is állja meg a helyét, illetve már a 2006-os konfon is vitatkoztam egy sort az akkori főnököddel, aki folyamatosan próbált meggyőzni arról, hogy az már rég rossz, ha a PHP vesz részt az oldal generálásban, miközben már akkor a Jasminnál kitoltunk 70-80 oldalt millió full dinamikus oldalt 7-8 szerverrel. Ráadásul a db HA része azon alapult, hogy myisam tábla legyen, amit kb. sehol sem ajánlanak komoly, replikált környezetben, ráadásul tranzakció sincs, aminek a feleslegességéről sizntén próbált meggyőzni.
“nem az van, hogy megírják a cikket, majd az kikerül az éles szerverekre”
Ez szintén olyan, azér mert a NOL esetében így ment, ez semmit nem jelent. Elég sok helyen dolgoznak az éles DB-be, ettől még simán lehet bármilyen workflowt biztosítani. Ha az index elműködik így, akkor talán működőképes modell.
Szerintem a legfontosabb rész nem került említésre: egy nagyterhelésű oldal esetén a DB a kulcs, a többi kis túlzással máz. A DB skálázhatóságát a legnehezebb megoldani, illetve ha komoly terhelés van, akkor ott van a legtöbb trükközésre szükség. Nyilván a körülötte lévő dolgoknak is klappolni kell, de a DB a lelke az egésznek.
Üdv,
Felhő
A magic_quotes-ot érdmes lenne kikapcsolni.
Hodicska Gergely: A Publishinget ne keverjük ide több okból se. Egyrészt már jóideje nem dolgozom nekik, tehát fogalmam sincsen hogy mi az álláspontjuk, másrészt pedig mind amikor dolgoztam nekik, mind pedig most is PHP szolgálja ki a címlapokat. Szóval vitatkozz velem, és nem velük, mert csak elbeszélés lesz egymás mellett.
A személyes véleményemet írtam le, nem pedig másokét. Az egyik – nem tudom leírhatom-e a projekt nevét – oldalnál amit a Wish szárnyai alatt fejlesztettünk, statikus kiszolgálásra épülő cache megoldást használtunk sikeresen, a belépett felhasználók számára pedig egyéb cache megoldásokat. Ez igen jelentős teljesítmény növekedést okozott, és lehetővé tette hogy ne kelljen extrém mennyiségű szervert beállítani (1-2-vel többet kellett volna, feleslegesen). Kívülről úgy látszik, illetve régebben úgy hallottam, hogy az Origo is ilyen megoldást használ, sőt, ők teljes egészében legenerálják az összes oldalt(?). Az Index úgy látom hogy PHP-vel szolgálja ki a “/” címlapot, míg teljesen PHP nélkül a “/index.html”-t, ez vagy hiba, vagy én látom rosszul. Valószínűleg a PHP szerepe – ha van – a statikus file betöltése.
A DB-vel kapcsolatosan egyetértünk, azt kell valahogy ügyesen megoldani, hiszen PHP-s frontendből “bármennyi” beállítható. A Drupal esetén ezt is nehezményezem, hogy egyáltalán nem olyan szemlélettel készült (szerintem), ami mondjuk a DB írások és olvasások szétválasztását lehetővé tenné (master és slave szerverek felé), vagy hasonló módon valamilyen megoldást biztosítana skálázhatóságra. Persze nem zárom ki, hogy erre is vannak már megoldások, illetve a hozzászólásokat leszámítva egy hírportál olyan alkalmazás, ahol elég ritkán változik az adatbázis (ha vannak hozzászólások, azok lehetnek mind gyakoriak mind nem: a látogatottságtól, és a hozzászólási kedvtől ez persze függ – de pl. egy élő közvetítésnél el tudom képzelni a gyakori kommenteket).
Hodicska Gergely: Nem tudom ki kapcsolta be (ha bekapcsolta valaki egyáltalán, és nem egy WordPress hiba), majd utána járok.
Felhő: “Szerintem a legfontosabb rész nem került említésre: egy nagyterhelésű oldal esetén a DB a kulcs, a többi kis túlzással máz.”
Ezzel elvitatkoznék azért picit.
Szvsz rég rossz, ha a nagy tehelésű oldal kiszolgálásában hathatós szerepe van bármilyen összetett db backendnek. Oké, hogy abban van a tartalom, azt bögyözzük, azt mentjük és védjük. De a kiszolgálás során szerintem minden esetben elkerülhető az adatbázisban kotrás. Cache, cache, és egy kis gyorstár. 
Szóval nem statikus kiszolgálásról van szó, de a programkód futás minimalizálása és az adatbázis műveletek nullázása az igazán hatékony megoldás (már az éles, izom kiszolgálásban)
Az user kontribúciók esetében is meg van a módja annak, hogy ne egyből db-be pakolja a rendszer a tartalmat.
András: “A Publishinget ne keverjük ide több okból se”. De hát ezeket a példákat te hoztad fel.
(Tudom, hogy nem vagy már ott egy ideje.) Megfogalmazol egy kritikát, majd említed ezt a két oldalt, mint olyan rendszert ami működőképes ebben a környezetben, ebből szerintem nem olyan merész arra következtetnem, hogy egyet értesz ezzel.
És szerintem ez a full oldalt statikusan legenrálni módszer ma már eléggé elavult, nem működőképes modell a mai web2-es oldalaknál. Persze lehet olyan oldal, ahol beválik, de pillanatok alatt csak kötöttség lesz (lásd ne tegyünk a főoldalra szavazást), még szerintem egy hírportálnál is. Pl. van sok cikked, meg mindegyiken egy rakás tag (manapság ez már eléggé adott), a végén oda jutsz, hogy tovább tart a különböző tagek szerinti lapozós oldalakat legenerálni, mint ahogy invalidálódik az egész egy új cikk létrejöttével.
Nézz meg a témával foglalkozó konferenciák anyagait, már pár éve nem nagyn látsz ilyet, hogy generáld le a full oldalt, és jó lesz, mert nem illeszkedik a mai webes alkalmazásokhoz. Persze mint technika része lehet a repertoárnak helyenként.
Üdv,
Felhő
Cece: hol mond ez ellen annak, amit mondtam?
András olyan megoldást írt, hogy full statikus oldalakat generálunk, erre reagáltam. Ráadásul sok esetben nem tudod elkerülni a DB-t az oldal kiszolgálásakor, lásd pl. livejasmin.com, vagy most ustream.tv, a rendszer jellegéből fakad, hogy friss (vagy majdnem friss) adatokkal dolgozz, ami mellett persze ott van ahol csak lehet a memcache.
De szintén tudom ajánlani, hogy nézd meg pl. highscalabilty.org-on a nagyobb oldalak felépítését, töbszáz query per sec megy replikánként a DB-be akár, nem mindegy, hogy milyen queryk, hogyan van felépítve a DB (gyakran nem a 3-as normál forma a nyerő).
Üdv,
Felhő
Hodicska Gergely: Utólag elolvasva is szerintem azt írtam, hogy konkrétan ismerek pár olyan oldal mögött levő megoldást, mely életképes nagy látogatottság mellett is, és ezek között hoztam fel az említett két oldalt (előtte a Netvibes-t, utána pedig a Magyarország.hu-t is). A cél az volt, hogy az eddig több helyen konkrtéan tapasztaltak és az innen-onnan hallott (Indexes, Origos) megoldások nincsenek szinkronban a Drupal általi megoldásokkal.
Nem azt mondom hogy generáljuk le az összes oldalt full statikusan – ez valóban teljesen elavult -, hanem azt, hogy a címlapot (nem az összes oldalt, azok látogatottsága jellemzően jóval kisebb a címlapénál) statikus tartalomként szolgáljuk ki a nem bejelentkezett felhasználók számára (konkrétan nem feltétlenül kell ezt sem generálni, elég első futáskor kiírni statikus tartalomként – hívhatod cache-nek is de nálam nem az). Azért jelzem, hogy eddig tudtommal egyik hazai nagy látogatottságú hírportál jellegű oldal sem jutott még el a címkék és egyebek használatáig, és most nem egy általános nagy látogatottságú oldalról, hanem konkrétan egy hírportál jellegű oldal optimális kiszolgálásáról beszélgetünk. Neked milyen tapasztalatod van ilyen oldalak kapcsán?
Más oldalaknál más jellegű üzemeltetési stratégiák kellenek, itt ilyen jellegűek.
Hodicska Gergely: úgy tűnik elbeszélünk egymás mellett. Nem mai webkettes oldalak üzemeltetéséről van szó ebben a blogbejegyzésben, hanem hírportálokéról, Szabolcs is ezt az oldalt képviseli, és maradjunk is meg ennél a témánál.
Egyébként közösségi oldalak szempontjából abszolút jó választásnak tartom a Drupalt, persze ha nagy látogatottságról van szó, akkor ebben az esetben sem árt mögé üzemeltetési tapasztalat.
Szerintem egyről beszél itt mindenki, csak a fogalmak keverednek. Nekem egyedül az a mondat ütötte meg szemem, hogy a db backenden múlik a dolgok java. Ezzel az eggyel nem értek egyet. A közösségi oldalakra is igaz, hogy nagyságrendi különbség van az írások és olvasások közt. Pörgős, de nagy látogatottságú közösségi oldalaknál az ember szempontjából a pár másodperces élethosszú cache nem érzékelhető, a gép szempomntjából viszont már az is hatalmas nyereség. De egyébként igen, közösségi oldalaknál, azaz ahol a tartalom igen pörgős, komolyabb szerephez jut a db. Egy “közönséges” hírportálnál, még ha van is kis közösségi beütése, szinte 100% megkerülhető az adatbázis kapcsolat.
Maga a statikusra buildelés és annak kiszolgálása a mai körülmények közt valóban kevés, elévült. No de a buildelt, sovány kóddal rendelkező címlapok, ahol a szavazás sem db-vel megy első körben (memcache vagy akár shm) szerintem továbbra is korszerű.
Szóval Felső is azt gondolja, hogy a db hívásokat vissza kell szorítani, és más sem monja azt, hogy a statikusra generált oldalak a nyerők. Szóval egyről beszélünk, csak mindenki hülyeséget feltételez a másik mondanivalója mögé…
András: “A cél az volt, hogy az eddig több helyen konkrtéan tapasztaltak és az innen-onnan hallott (Indexes, Origos) megoldások nincsenek szinkronban a Drupal általi megoldásokkal.”
Pl. az Origo-n is van szavazás, és mint ahogy a zoom.hu-n egy külön végoldalon mutatja meg a végeredményt, tehát nyugodtan lehet statikus a főoldal. Az indexnél is masszív cachelés megy, és dinamikusan áll össze a címlap (bár ebben csak majdnem vagyok biztos).
“és most nem egy általános nagy látogatottságú oldalról, hanem konkrétan egy hírportál jellegű oldal optimális kiszolgálásáról beszélgetünk.”
“Neked milyen tapasztalatod van ilyen oldalak kapcsán?
”
Az indexnek a cikk kereső és listákat karbantartó modulját én írtam. Persze lehet, hogy került ez elé még egy réteg, akár pl. egy reverse proxy is lehet, de nem tudok róla, meg fogom kérdezni.
Üdv,
Felhő
Bocs, de ez nem derült ki a címből számomra, illetve a cikk egészéből.
Hodicska Gergely: A zoom.hu nem egy külön oldalon mutatja meg a végeredményt, hanem a címlapon: http://screencast.com/t/6WvZVqsb Értelemszerűen nem arról beszélek, hogy nem lehet kinn form.
Lehet hogy konkrétabb is lehettem volna a címben a téma megjelölését illetően.
Cece: “Nekem egyedül az a mondat ütötte meg szemem, hogy a db backenden múlik a dolgok java.”
Én azt látom, hogy a DB-vel kapcsolatban van a legtöbb “nem szokványos” munka egy nagy terhelésű oldalnál (de írtam is, hogy persze sok más aprósággal kapcsolatban is észnél kell lenni). Az egész cachelés téma fő szerepe, hogy csökkentsd a DB terhelését, de ezzel együtt egy adott terhelés felett elérkezik az a pont, amikor az egy master DB nem fogja bírni az írást, és akkor már nem segít a repliklás, cachelés, hanem valamilyen szintű particionálásra van szükség (és manapság a charding fele mennek a nagyok, tehát lakalmazás szintű particionálás). És ha ez nem volt betervezve az elejétől kezdve, akkor ez egy igencsak fájdalmas pont tud lenni a fejlesztésben, mert sok mindent alapjairól kell újragondolni.
“Szóval egyről beszélünk, csak mindenki hülyeséget feltételez a másik mondanivalója mögé…”
Hülyeséget még véletlenül sem feltételeznék, csak messze nem gondolom kizárólagosnak a fent leírtakat (a vita témája szempontjából), és azt tapasztalom illetve látom, hogy sok helyen igencsak másképp működnek a dolgok.
Amúgy pl. abban egyet értek, hogy én sem ugranék neki egy tényleg nagy terhelésűnek szánt oldalnak drupallal, de ez kb. igaz lehet sok más frameworkre is. Bár lehet, hogy ha Goba lennék, akkor már bátrabb lennék ezen a téren.
Egy könnyű, lightweight saját framework könnyen sokkal jobban tud teljesíteni, bár nyilván itt sok szempont szerepet játszik, adott esetben még két szerver olcsóbb lehet, mint pár fejlesztő 1-2 havi fizuja, szóval ez nem egyszerű probléma.
Üdv,
Felhő
Vicces
, nyilán kipróbáltam mielőtt ezt írtam 
:
http://www.screencast.com/t/U26zHR9N4E
Üdv,
Felhő
http://buytaert.net/motogp-using-drupal :
MotoGP is the world’s premier motorcycling championship, with a season of 18 Grands Prix in 14 countries bringing together the world’s top motorcycle manufacturers such as Honda, Yamaha, Suzuki, Ducati, Kawasaki, Aprilia and KTM – plus an elite crop of riders from every corner of the globe. Their website just relaunched on Drupal: see http://www.motogp.com. Rumor has it that on racing days, they serve up to 2 million pages a day. Yowza!
Véleményem a cikkről:
http://drupal.hu/node/3949#comment-14872
(nem kellett volna belenéznem a zoom.hu forrásába… argh.. legalább egy tréningre eljöhettek volna hozzám a srácok… devel modul éles rendszeren jézusom…)
pp
Hojtsy Gábor: Azt hiszem, ez a nem semmi… pláne ahogy elnézem, ötös Drupallal dolgoznak, és úgy tapasztaltam, a hatos még jobban bírja a terhelést.
Palócz István: köszönöm neked is a korrekciót, illetve a bejegyzés helyes irányokba terelését. Helyben a Drupal.hu-n reagáltam.
Tényleg nem a kötözködésért, de te magad is elismered, hogy már régen foglalkoztál a Drupallal, és jó ideje nem is követed nyomon a fejlesztését…
Közben a http://drupal.lap.hu/ oldalon a “Drupal arcok” link-dobozban az első helyen szerepelsz…
Szóval érdekes ez… :S
Hoopá, elnézést, csak most nézem, hogy: “Az oldalt szerkeszti: palocz.istvan”
NeverGone: régen foglalkoztam mélyebben a Drupallal, de nyomonkövetem a fejlesztését, tisztában vagyok a 6.x újdonságaival. A drupal.lap.hu-t pedig nem én szerkesztem, nem is tudtam, hogy kinn vagyok.
Mert névsorban van… (Aires pedig Fehér Jánosként került bele azért van ott ahol van.
)
András kivegyelek?
pp
Palócz István: igen, lehet hogy ki kéne vegyél.
hello!
én is szeretnék csinálni egy nagyobb hírportált, de meg szeretném kérdezni, hogy tudja-e valaki, hogy mire épül az index és az origo?
mert én drupalra gondoltam, de ezek után…:D
köszönöm előre is!
Császár Richárd: Ne csinálj nagyobb hírportált. Mind az Index, mind az Origo saját szerkesztőségi rendszerrel dolgozik.
András: nowpublic.com is drupal alapú, mégis elketyeg valahogy.
Üdv,
Felhő
Hodicska Gergely: Persze. És ez hogy jön az általam írottakhoz? Azt írom én is, hogy megoldható.