Technológia: III. rész - Cache

2006.02.16. 14:30 bazso

Szigorúan csak érdeklődöknek egy kis betekintést szeretnék nyújtani az iWiW mögötti cache-elési technológiák bugyraiba. Ha nem tudod, hogy az informatikában mit is jelent pontosan a cache szó, hogy mire való, akkor ettől a bejegyzéstől sem leszel feltétlen okosabb.

I. Mit is cache-elhetünk?

A kérdés nem is olyan egyszerű. Html szinten cache-elni az iwiw esetében nehéz, nagyon sok minden perszonalizáltan jelenik meg, nagyon sok a dinamikusan változó adat. Persze, ha egy nagy forgalmú oldalnál ha csak másodpercekre, de a gyorsítótárában tud az ember tartani tartalmakat, nagyon sokat nyerhet vele. Csak aztán arra kell odafigyelni, hogy nehogy az cache item-ek invalidálása vigye el a sok időt. Ami már majdnem html szintű cache, az a felhasználók által beírt nyers szövegek "parse-olt" verziójának gyorstárazása (linkek, emótikonok felpakolása, stb.).No, de kicsit elkanyarodtam az alap kérdéstől. Szóval html-t cache-elünk, de nem számottevő mennyiségben.

A második, jelentősebb cache az iWiW alatt az adat (objektum) cache. Szinte minden adat bekerül a cache-be, csak a nagyon gyakran változó adatok nem. A legfontosabb, hogy az adatbázis tehermentesítve legyen minél jobban, hiszen éppen elég kérést kap olyan funkciók használatával, amelyeknél nincsen lehetőség cache-elésre.

II. Hogyan is cache-elünk?

A képek gyorsítótárazásáról már volt szó, úgyhogy inkább az egyéb cache megoldásainkról írnék. Igazából két nagy csoport van, az in-process cache és az out-of-process cache, hogy melyikben mit cachelünk, az üzleti logikai kérdés volt, és nem a cache-elendő adat típusa határozta meg. Tehát ugyanúgy vannak mindkettőben objektumok, html darabok, stringek cache-elve.

in-process cache
Az in-process cache lényege, hogy egy alkalmazásszerver JVM-jén belüli cache-ről beszélünk. Mindegyik alkalmazásszerver magának cache-el, a többi gép broadcast üzenetekben értesül arról, ha valamelyik cache elemet üríteni kell a cache-ből (flush), mert változott, vagy törlődött.
Az in-process cache-re az OpenSypmhony által fejlesztett OSCache-t használjuk, a clusterelt működésben pedig a JGroups segít.

out-of-process cache
Az out-of-process cache lényege, hogy az alkalmazások egy vagy több közös cache szervert használnak, így egy adatot csak egy appservernek kell betöltenie, a többi már tudja rögtön a cache-ből használni azt. Ugyanez igaz az elemek invalidálására is, az egyik appservernek elég flush-olni az elemet a cache-ből, a többi appserver ezután már nem fér hozzá az adathoz. Itt a memcached-et használjuk, iszonyúan ütős, hatalmas teherbírású cucc, tényleg csak ajánlani tudjuk! Van hozzá php-s, java-s, .net-es (C#) kliens API, úgyhogy még az alkalmazott platform sem szabhat határt (igaz, unix/linux környeztben fut csak, habár már készült win32-es verzió, de még nincs sok bíztató adat vele kapcsolatban). Csak egy érdekes adat by leczb: a memcached pillanatnyilag 4000-5000 read req/s tol ki magából, 85%-os hit rate-el (magyarul a kérések 15%-a jut csak el az adatbázisig). A másik érdekes adat pedig, hogy 2-3 nap alatt a memcached szerver forgalma eléri a 2-3 Tbyte-ot...


III. Amit mi hozzátettünk

Az előzőekben leírtam, hogy milyen cache megoldásokat alkalmazunk, valamint hogy körübelül hogyan határoztuk meg a különböző gyorsítótározandó (de szép szó :]) elemeket. Azonban szükségünk volt arra, hogy maga a cache funkcionalitás egy külön réteg legyen az alkalmazásban, könnyen ki és be lehessen rakni alá objektum típusokat, sőt az is legyen megváltoztatható, hogy az objektumok, elemek éppen in-process vagy out-of-process cache-be kerüljenek.

Ezen probléma megoldására készítettünk egy saját cache réteget, amelyet összeházasítottunk az adatelérési rétegünkkel. Így nyertünk egy szabadon konfigurálható cache réteget, ahol beállítható akár több in-process és out-of-process cache repository, a különböző repository-k esetbén meghatározható, hogy milyen elemek kerüljenek bele, hány kerülhet bele, FIFO (First-In-First-Out: a legrégebbi elemek) vagy LRU (Least-Recently-Used: a legkevésbé használt elemek) algoritmussal pörögjenek ki a cache-ből az elemek, és hasonló nyalánkságok :).



Röviden ennyi, persze ez egy eléggé gyors áttekintő volt, de remélem érdekes/hasznos sokatoknak.

61 komment · 1 trackback

Címkék: tech szoftver szerver cache squid memcached oscache

A bejegyzés trackback címe:

http://iwiw.blog.hu/api/trackback/id/tr254663

Trackbackek, pingbackek:

Pingback: dev2 - webfejlesztés » IWIW és a 900Mbit/s esete 2007.08.17. 06:51:46

[...]target="_blank">http://iwiw.blog.hu/2006/02/12/technologia_ii_resz_szoftver http://iwiw.blog.hu/2006/02/16/technologia_iii_resz_cache_1[...]

Trackback: Techies blog 2006.02.16. 21:01:54

iWIW technológiai háttérAz iWIW blogban bukkantam rá néhány érdekes bejegyzésre, ami a rendszer hardver hátterét és az alkalmazás felépítését boncolgatja. A hardver…

Pingback: Techies blog » iWIW technológiai háttér 2006.02.16. 21:01:39

[...] acute;sLink: Technológia: II. rész - SzoftverLink: Technológia: III. rész - CacheLink: Hardver architektúra & [...]

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

szabo 2006.02.16. 14:46:47

Szeretném ha a többiek nem látnák az adatlapon az e-mail címem. Hol tudom letiltani???

m

xmeNTor 2006.02.16. 15:01:25

Köszi a leírást! :) Akit érdekel, annak mindenképp hasznos, ne hallgass azokra, akik szerint nincs értelme kifejteni így a rendszer működését :)
Így tovább! :)

kobak · http://www.kobak.org 2006.02.16. 15:25:22

Meg csak atfutottam rajta, de szerintem is hasznos olvasmany! Csak igy tovabb!

brekee 2006.02.16. 15:33:58

Egyre durvul a tech rész, de én élvezem. :) méééég!

PAStheLoD · http://pasthelod.ashes.hu/ 2006.02.16. 15:38:37

Igen, egyértelműen süllyedünk, bele a tech-levesbe, de mehetünk mééég mélyebbre :D

PAStheLoD · http://pasthelod.ashes.hu/ 2006.02.16. 15:45:43

A fórumon megjelenő [amúgy naggyon szép :D] kis emotikonokat kell gondolom belefordítani (nyers szövegből html-be) a kimenetbe. Ezt mért nem alapból így [html-estül] tároljátok.. aztán, ha változik valami, akkor arra írni egy pár függvényt, hogy a régi szövegeket lekérésnél átírja az újra és vissza is írja a DB-be a frissített verziót.

Jóval macerásabb, de mindent a teljesítményért, nemde? :] Ha ezen 2 módszer közül egyiket se használjátok, akkor kíváncsi lennék, hogy hogyan tároljátok az adatokat az adatbázisban.. :)

Meg ha 2-3 Tbyte-ra rúg pár nap alatt a memcahed forgalma, akkor mégis, mekkorák az adatbázisok? :0

gab 2006.02.16. 15:48:12

köszi az infót annyi okosabb nem lettem ,de 1 picit talán,thanks!

bazso 2006.02.16. 16:01:58

PAStheLoD:
"A fórumon megjelenő [amúgy naggyon szép :D] kis emotikonokat kell gondolom belefordítani (nyers szövegből html-be) a kimenetbe. Ezt mért nem alapból így [html-estül] tároljátok"

lásd:

"...Ami már majdnem html szintű cache, az a felhasználók által beírt nyers szövegek "parse-olt" verziójának gyorstárazása (linkek, emótikonok felpakolása, stb.)..."

tehát úgy tároljuk, ahogy írtad :)

P.A. 2006.02.16. 16:28:58

ha ennyit cache-eltek, miért nincs AJAX? szerintem nagyban csökkentené a szerver load-ot - vagy fontos a magas pageimpression? ;-)

Seth 2006.02.16. 21:43:16

hmm.. hmm.. gyorsabb proc, több memória, es pingvin lehet a megoldás :D

dawid · http://dawid.hu 2006.02.16. 22:05:13

Köszi, ezek a leírások sok dologban segitenek tervezgetni a dolgaimat ;)

Yakecan 2006.02.16. 23:18:20

Ha a memcached több gépen fut párhuzamosan akkor szinkronizálnak vagy azt magadnak kell megoldani?

PAStheLoD · http://pasthelod.ashes.hu/ 2006.02.16. 23:32:28

gondolom több gépen .. azért 4000 req/s -et 1 gépről .. hmm impresszív vas lenne :D

konyak_ad 2006.02.16. 23:44:04

Szia bazso,

Azt írtad, a képek gyorsítótárazásáról már volt szó - hol? Ennyire vak vagyok? Pedig elolvastam a másik két tech doksit is.

Egyébként tőletek csórva az ötletet, beizzítottam a memcached-t, tényleg zúz szépen, a db-szerver loadját 20-ról 2-re csökkentette. (hogy a site micsoda, titok, ez nem a reklám helye) Kösszépen, már megvan az új vas, de minek!? :)

glacy 2006.02.17. 08:15:36

Yakecan, memcached szerverek nem szinkronizálnak, éppen az a lényegük, hogy ne nagyon tartalmazzanak redundáns adatokat. a hozzájuk írt kliensek a tárolás előtt egy belső hash algoritmus alapján választják ki, melyik kulccsal melyikhez forduljanak.
engem azért jobban érdekelne, mi is az, amit hozzátettetek, esetleg pótoltátok-e valamelyik komponens hiányosságait? írtatok talán egy új klienst a memcachedhez, amivel esetleg egy kieső szerverrel sincs elveszett adat? na az már engem is érdekelne :)

konyak_ad 2006.02.17. 09:26:49

Jahm, Squid. Bocsi, tényleg vak vagyok. Azt hittem hosszabb rész szól róla, és bonyolultabb :))

zfor 2006.02.17. 09:27:52

PAStheLoD: márpedig a srácok azt írták, hogy a memcached egy gépen fut.

Objektum-cache szerver (MEMCACHE)
1x AMD Opteron 2.6GHz, 4Gbyte RAM, 2x80Gbyte SATA HDD (RAID1)

Ld. Tech I.

leczb 2006.02.17. 09:30:20

Yakecan: több memcached instance = load balancing, tehát nem rundáns a tárolás. glacy jól írta: szét lehet osztani az objektumokat a memcached instance-ok között az object id-k hash értéke alapján.

PAStheLoD: jelenleg 1db dedikált memcached gépünk van (memcache1 a Tech I. post ábráján). Eddig csúcsban 5200 read req/s-et láttunk tőle kiszolgálni (600 write req/s mellett), ekkor 170Mbit/s volt a kimenő forgalma a gépnek (Gigabit porton van természetesen) és 0.7 volt a load.

Yakecan 2006.02.17. 10:33:57

leczb: Akkor jól sejtem, hogyha most kidöglene a memcached szerveretek akkor az egyenlő lenne a katasztrófával?

leczb 2006.02.17. 11:00:18

Yakecan: ha arra gondolsz, hogy hardver szinten
kidöglene, akkor az nem okozna nagy problémát: k.b. 4-8 perc downtime lenne (amíg egy másik node-ra áthelyeznénk a szolgáltatást: mindenhol installva+konfolva van, csak a el kell indítani) + k.b. 1-2 órányi degradált
szolgáltatás (amíg felszívja magát a cache), amíg elhárítjuk a hardver problémát
(értsd: kicserélnénk alatta a vasat).

konyak_ad 2006.02.17. 13:23:40

leczb: miket tároltok a memcache-ben? Ezt hiányoltam. Komplett DB-t? A 15% ami eljut a DB-szerverig, hogy jön ki, ennyi az írási (update, insert) művelet?

leczb 2006.02.17. 13:31:26

konyak_ad: a válasz az eredeti Tech III. post-ban van (lásd: out-of-process cache rész).
Leegyszerűsítve: ha az alkalmazásnak szüksége van egy üzleti objektumra, akkor a cache-hez fordul.
Ha abban nem találta (cache miss), akkor kérdez
csak be a DB-be (és miután összerakta az
objektumot a DB-ből szerzett adatokból, be is
teszi a cache-be).
A cache hit rate 85% körül van,
tehát a beolvasási kérések 15%-a terheli csak
a DB-t, 85%-a cache-ből jön.
A cache hit rate-ünk tovább fog javulni, amint
még több memcached instance-ot állítunk csatasorba.

katacs 2006.02.17. 14:47:38

Nem tudom, miért, de én nem kaptam átadható meghívót. mégis szeretnék meghívni egy kedves barátot. Hogy tehetném meg? És miért nem kaptam meghívót?
Kösz

Yakecan 2006.02.17. 14:50:33

leczb: a (de)szerializáció nem visz el túl sok erőforrást?

leczb 2006.02.17. 14:57:13

Yakecan: nem elhanyagolható a (de)szerializáció erőforrásigénye, de nem is gyilkos méretű. valahol meg kell fizetni az adatbázis tehermentesítésének árát. az objektumok-nál törekedtünk az egyszerűségre (string, int) és a kis méretre, hogy a (de)szerializáció minél hatékonyabb legyen.

Yakecan 2006.02.17. 15:17:11

leczb: köszi a választ!

Donát 2006.02.18. 10:24:23

Hali!
Nem igazán ide kötődi ka kérdésem, de felteszem...Az éveim száma magától fordul át, vagy nekem kell VALAHOGY átumbuldálni, mert még nem jötte mrá, hogy kéne, ha igen...
???
Tisztelettel egy felhasználó...

Magyusz 2006.02.18. 13:37:00

Számomra furcsa az a megközelítés, hogy az objektum cache nem ül teljesen az adatbázis fölé, hanem néha közvetlenül éri el az üzleti logika a dbt. Még furcsább, hogy a cache nem magát menedzseli, hanem néha dupla munkát ad ("és miután összerakta az objektumot a DB-ből szerzett adatokból, be is teszi a cache-be") az olyan folyamatoknak, amikenek lehetőleg csak a felhasználók gyors kiszolgálásával kéne törődniük. Még ha ez nem is a felhasználó idejének rablásával (http kérés-válasz közben), hanem a kiszolgálás után vagy külön szálban történik, akkor sem tartom szép megoldásnak.

Ha csak a objektum cache tartana kapcsolatot a DB-vel, akkor ő egymaga kezelne connection poolt, query / (prepared) statement cachet, ami egy-egy appserver szintjén, de főleg rendszer szinten érezhető javulást hozna.

Az írási műveletekről nem írtatok, de ha jól sejtem, akkor a cache mögé írtok, ugye? A Lucene ilyenkor valamilyen interceptoros megoldással az írási tranzakcióban indexel, vagy utána?

---

Elszakadva a jelenlegi konfigurációtól, én inkább több vasat tettem volna DB clusterbe, és megfontoltam volna a tárolt eljárások használatát, mert érzésem szerint nem futnak veszettül bonyolult algoritmusok, viszont adatintenzív az alkalmazás. Annak, hogy DB helyett app server + cache irányba erősíte(tte)tek mennyire voltak szakmai és mennyire egyéb (pl. főtámogatók irányultsága) okai?

Shenpen · http://www.valodi.hu 2006.02.18. 14:40:37

Tény, hogy már nem tetű lassú a WiW és ez előrelépés, de a megoldás nem csak a kesselés, hanem az Ajax lenne. Miért kell pl. az egész oldalt újra leküldeni a browsernek, amikor belép a júzer egy fórumtopikra, miért nem csak azt a részét?

Ha esetleg nem ismernétek, az AJAX egy olyan technológia, hogy XMLHttpRequest JavaScript hívással az ember az oldal mint XML dokumentum egy részét cseréli ki és nem rendereli újra az egészet.

PAStheLoD · http://pasthelod.ashes.hu/ 2006.02.18. 14:42:42

leczb: oh, elnézést a tévedésemért és köszönöm a pontosítást :)

5200 query.. nem gyenge, ezek mennyi időt vesznek igénybe átlagosan?

A kapcsolati hálót hogy tároljátok? Egy szép nagy táblában? Esetleg egy táblában a pontokat, egy másikban pedig az éleket ?

leczb 2006.02.18. 15:14:34

PAStheLoD: a kapcsolati hálót perzisztensen két táblában tároljuk: az egyik a "csomópontok" (felhasználók), a másik az "élek" (kapcsolatok).
A "Legrövidebb út", "Közös ismerősök", "Kit ismerhetek" lekérdezéseket nem ezen a struktúrán futtatjuk: erre van egy daemon (wiwd), ami induláskor
felolvassa RAM-ba ezeknek a tábláknak a tartalmát és a felépített gráfban keres. Ez a daemon természetesen az applikációtól megkapja a módosítási parancsokat, hogy szinkronban maradjon a táblákkal (új felhasználó/törölt felhasználó, új kapcsolat/törölt kapcsolat).

PAStheLoD · http://pasthelod.ashes.hu/ 2006.02.18. 15:26:26

Akkor egészen jól tippeltem, kösz :)

Btw, esetleg van valami lehetősége exportálni a levelzést? Vagy csak törölni és törölni? Persze nem mintha olyan fontos dolgokról lenne szó :)

leczb 2006.02.18. 15:27:12

Magyusz: van tapasztalatod DB-cluster-ben futtatott üzleti logikával kapcsolatban vagy csak érzés alapján írod, hogy te abba az irányba mentél volna?

Az eddigi Tech I-II-III. post-okban nem írtuk,
de sokminden tárolt eljárásként fut az adatbázis
szervereken belül: a módosítási műveletek túlnyomó többségét tárolt eljárás végzi. A lekérdezések azonban tiszta SQL.

A vassal kapcsolatban: jóval egyszerűbb APP szervereket hozzáadni egy rendszerhez, mint
egy DB szervert vertikálásan skálázni (és esetleg fizikai korlátokba ütközni) vagy DB cluster-t felépíteni/bővíteni (+ még egy entry level SAN is nagyon megdobja a költségeket).

csj · http://blogs.sun.com/csj 2006.02.21. 10:15:53

"jóval egyszerűbb APP szervereket hozzáadni egy rendszerhez, mint egy DB szervert vertikálásan skálázni (és esetleg fizikai korlátokba ütközni) vagy DB cluster-t felépíteni/bővíteni (+ még egy entry level SAN is nagyon megdobja a költségeket)"

Ez így van, de hosszútávon (értsd: kapok végre egy meghívót és behívom Jonathan Schwarz-ot a wiw-re, akivel meg hosszútávon jön a fél USA:) szerintem több komoly feladat lesz a cache disztributálásával, cache koherencia fenntartásával, mintha mindezt DB szinten bazinagy gépek alátolásával oldaná meg a rendszer.

Olyanban nem gondolkodtatok, hogy a felhasználók kezelését, authentikációját és lekérdezését betoljátok egy LDAP-ba? Érzésre jóval több az olvasási, mint az írási művelet egy normális Directory Server-rel a másodpercenkénti néhány tízezer lekérdezés is elérhető több milliós adatstruktúrán, ráadásul a replikációja is könnyebb és egyszerűbb, mint DB-ben tárolt adatok esetén.

csj · http://blogs.sun.com/csj 2006.02.21. 10:17:23

Mondjuk azt tudom, hogy Magyarországon viszonylag ismeretlen technológia az LDAP címtár, az egyetemeken sem nagyon tanítják...

leczb 2006.02.21. 10:32:55

csj: nem ismeretlen számunkra az LDAP technológia, de mivel nem szűk keresztmetszet a felhasználó authentikáció, nem tervezzük az alkalmazását.

leczb 2006.02.21. 10:39:59

csj: cache koherencia problémánk nincsen, mert centralizált a cache rendszerünk. ez nem akadályozza meg a horizontális skálázhatóságot, mert object id hash alapján szét lehet osztani több cache szerver között a terhelést.

csj · http://blogs.sun.com/csj 2006.02.21. 12:56:32

"mert object id hash alapján szét lehet osztani több cache szerver között a terhelést."

Az iwiw egy skálafüggetlen hálózatot térképez fel. Csodálkoznék, ha egy statisztikai alapon létrehozott particionálás egyenletes terhelésűre megosztott cache-eket alakítana ki. Bár ez talán annyira nem probléma, mert a felhasználó csak annyit lát belőle, hogy az egyik user adatlapja azonnal lejön, a másiké pedig 2-3 mp-cel tovább töltődik (leegyszerűsítve a dolgot).

LDAP-ot azért emlegettem, mert akkor a user-eket ki lehet venni a cache-ből: maguk az LDAP szerverek is lényegében akkor működnek jól és gyorsan, ha a teljes adatbázis elfér memóriában (nem hiába használják telco-k az akár több milliós ügyféladatbázis tárolására).

Magyarul egy olyan adatbázis, amit nem kell cache-lni és ha belassul, akkor horizontálisan nagyon szépen skálázható.

IBM-es mainframe-es körökben mindenféle hardvereket tervezgető ismerősöm mesélt olyan öreg szakikról, akik kihúzattak mindenféle cache-lési megoldást a tervezett hardvereszközből, mert nem-determinisztikussá tehette az egység működését, és nagy terhelés alatt többet ártott, mint használt... Azóta ez a példa lebeg a szemem előtt. De biztosan ismeritek a régi programozói mondást: "Do not optimize"... illetve "Do not optimize yet" :)

Bluebier · http://www.cheatteam.net 2006.02.21. 15:32:23

Egyre jobb a leírás, csak szerintem az a baj, hogy aki nincs benne ebben a témában az egyre jobban kezdi nem érteni. (szerintem) De nekem tetszik abból a szemszögből, hogy sokan meglátják azt, hogy egy nagy portálnak mekkora is a gépigénye, és software követelménye. :)

newl 2006.02.21. 20:25:54

Nem tudom, hogy volt-e már szó róla, de csak egy gondolat...
Az email értesítőket alapesetben nem lehetne úgy beállítani a júzereknek, hogy pl csak bejelölés, vagy elfogadás esetén küldjön mailt?
Ha jól emlékszem a default beállítás minden egyes esetben küld üzenetet. Ez nemgyenge forgalmat generálhat... Bár nem mintha ez segítene az érdemi problémákon, csak átfutott az agyamon.
Ha említették már máshol, akkor szorri.
Üdv.

Gazsi · http://kep.tar.hu/gazsie 2006.02.22. 16:59:09

buta kérdés:...és ha a regeket meg a sok erőforrásigényes módosítást később, mondjuk a nap nem túl leterhelt időszakában hajtaná végre a Felügyelő Bizottság :-) ?? ide értve a képek kiküldését az oldalra, vagy a profilok módosítgatását, meghívó kiküldését? szerintem mindeni kibír fél napot, az egész rendszer viszont gyorsabb lesz...nem?

zoli 2006.02.22. 18:37:42

mujeres-egyetertek vele!
Mindenki szamara negativ ez a lassulas.

érdeklődő_#001 2006.02.23. 16:46:09

Először is szeretnék gratulálni a rendszerhez! :-)

A második dolog pedig egy-két kérdés lenne, mint érdeklődő, hátha tudok segíteni valamit, illetve kíváncsi is vagyok (bocs az okoskodásért illetve az olyan dolgokért, amit már ezerszer végiggondoltatok :-).

1. Milyen teszt, demo rendszeretek van? Gondolom van valami, ahol kipróbáljátok először a fejlesztéseket, de azt is gondolom, hogy az a rendszer nem 9 appszerverből áll. Hogy tudjátok így kipróbálni a fejlesztéseket?

2. Az (app)szerverek között milyen hálózati kapcsolat van? Ez nem szűk keresztmetszet?

3. A server gépek CPU és i/O terhelése hogy néz ki? Melyik mivel tölti az időt? Ha pl. az adatbázis sokat I/O-zik, akkor lehetne-e bele még memóriát rakni?


4. Gondolom, a kapcsolatokat tároló tábla szép nagy. Lehetne-e ezt darabolni? mondjuk ha a user ID 0-10000 között van, akkor a tabla_1 tárolja a kapcsolatatit stb.


5. EJB-k vannak használva? Ha igen, a remote interfészek nincsenek túlzásba víve?


herka 2006.02.24. 08:07:37

És mi lesz, ha mindenki elküldi a meghívóját?

Nucc 2006.02.25. 19:23:36

Lehet, hogy bika háttér van mögöttetek, meg sok gép, de a rendszer akárhogy is nézzük szar... Már bocsi a kifejezésért, de ennyi géppel, ekkora látogatás mellett, na mind1.... A képekre, nem hazudok, van úgy hogy egy percet kell várni. Csak nehogy a sávszélességre fogjátok! Szóval annyira nem isteníteném magam a blogon

bsh 2006.02.27. 14:04:16

izé, nem tudom, jó helyre írok-e, de először is üdv mindenkinek!
az lenne a kérdésem, hogy nem lehetne-e kissé egyszerűsített formában is megcsinálni a wiw-et, hogy mondjuk mobilról wapon is normálisabban működjön? lehetne egy külön wap felület is, de elég lenne egy egszerűsített/optimalizált html is.
bye!

Delave 2006.02.28. 09:34:24

Sziasztok,

gondolkoztatok már egy moderátor csatasorba állításán, aki az offtopic kommenteket esetleg áthelyezné az őket megillető helyre ?
Nem nagy dolog persze, csak zavarja a szemem a sok meghívókuncsorgó(->topic:devnull)/miértlassúarendszer(->topic:mert)/hogyankellkattintani(->topic:google) témájú komment a nem odaillő helyeken.

Üdv,

Delave

TCM1976 2006.02.28. 12:57:43

Mostanában látom, hogy a google is bevásárolt magának szocháló építő oldalt (orkut.com). Nem féltek tőle, hogy megesz titeket az óriás?

csaba · http://websalata.hu 2006.02.28. 15:04:51

köszi a leírást!
Én is szeretnék bővebben olvasni a megvalósításról.

más: AJAX sztem mindenki tudja mi ez,elég nehezen hiszem, hogy ilyen cucc készítői ne tudnák. Szóval nem kell mindig írni, hogy ménemajax;

buki92 · http://www.whalin.com/memcached/svn/java_memcached/tags/release_1.3.2/src/com/danga/MemCached/ 2006.03.01. 04:39:07

Sziasztok!

Belkukkantottam a memcache Java API-ján a kódjába. (link a nevem mellett)
Szerintem elég gázos, ugyanis hagyományos socket kezelést használ, nem pedig NIO-t. Gondolom nem kell hosszasan magyarázni, hogy nagy forgalom esetén ég és föld a különbség a két socket kezelési mód között. (Van erről írás rengeteg, meg aztán nem is ok nélkül vezették be az új módit.)

Szóval nekem az a tippem, hogy akik a memcache-hez írták a Java API-t, azok alapvetően C programozók voltak, és a Java számukra csak egy nyelv a sok közül. Emiatt olyan finomságokra, mint a java.io és java.nio közötti különbség már nem figyeltek.

Szerintem egy próbát megérne, hogy átírjátok a SocketIOPool.java-t rendesen NIO-sra, és ráereszetek egy terhelési tesztet. Pár száz sor az egész, és meglepő javulást tud hozni.

(De, ha kell NIO témában segítség, nagyon szívesen ...)

atleta · http://www.atleta.hu/gm 2006.03.03. 05:07:06

Mamcached, chachinbg, whatever.... Talan megis csak az lenne az elso lepes, hogy kiszuritek a felesleges oldalletolteseket, meg ha ez rosszabbul is nez ki a statisztikaitokban (bar ezt ketlem, mert kurvara nem fogja erdekeln a hirdetoket, hogy egy user 500 vagy 100 requestet general naponta - sztem). Mondjuk, hogy ha listazza valaki a luzereket (kereses, ismerosok), es rakattint a kis kepre, akkor meg ketto plusz bokese (oldalletoltese) van, mielott megnezheto normalis meretben azt a nyamvadt kepet. Na most ez kinek jo? A luser szenved, nektek meg tovabbra is hiresen csiga lassu az oldalatok (es a luzer ettol is szenved, meg egy T1es vonal vegen is).

Irnek ehhez is Greasemonkey scriptet, de szerencsere nem igazan kitalalhato a kis kepbol a nagy kep URLje (ha jol latum), uhhoggy csak a user kepeket tartalmazo oldalara lehet ugrani (es ugy a 3bol csak 1 olalbetoltes - 33% - sporolhato meg). Azert hajra, es az egyszeru megoldasok helyett tovabbra is probalkozzatok csak a bonyolultabbakkal, hatha ti lesztek az elsok, akiknek ez jon be.

Kesztyű 2006.03.03. 19:25:38

Én nem értem miért vannak annyian elhűlve ebben a technologiában, engem csak az érdekel milyen programozási nyelven írtátok az 'IWIW' programját? Mármint ami a leveleket átadja, kiolvassa a szerverekből az adatokat és persze meghívókat küld.

snak3pit · http://snak3pit.deviantart.com 2006.03.07. 10:32:01

bocs, hogy ide pötyögök bele (nem biztos, hogy a legjobb hely), de eképzelhető, hogy operában is tökéletesen fog működni az iwiw, amiről ugye tudjuk, hogy sokkal szabvány követőbb, mint az ie. (és nem mellékesen, eleddig a legkevesebb biztonsági rés található benne). ne kényszerítsetek már pls az ie használatára, mert már akkor is remeg a kezem, ha az ikonja közelébe kerül a kurzorom :)))

bizonyos fokig megértem, hogy a legelterjedtebb böngészőn szeretnétek, hogy a legjobban fusson, de inkább legyen szabványos, és bátorítsátok a felhasználókat az alternatív böngészők kipróbálására is, lévén, hogy ingyenes, és nem kell technikai zseninek lenni hozzá, hogy valaki telepítse, és egy nyelvi file-t bemásoljon a mappájába. (máskülönben, akinek eddig ajánlottam, hogy használja egy kis ideig, és ha nem tetszik, visszatérhet ie-hez, hát... nem tért vissza:) )

jelenleg olyan kiábrándítóan bugos operában :(

byez all, szép napot és jó munkát

oops 2006.03.09. 12:37:58

IE: ez bizony bosszantó, a firefoxom állandóan elhasal, főleg a redirectek miatt, amit agresszív popupnak értékel. nem tudom, mennyire kellene a velejébe nyúlni ahhoz, hogy ez ne így legyen, de úgysem ússzátok meg. Az IE-t azért sem érdemes nagyon követni, mert a MSFT holnap gondol egyet, és ami ma működött benne (nem dokumentált feature-ként), az holnap irtandó sechole lesz.

Mi a DB mögötte? Nem mintha ennyi cache mellett nagy jelentőssége lenne, csak érdekel.

A sok suttyó, akit meg nem érdekel, téleg ne itt randalírozzon. Örüljön, hogy megtalálta az osztálytársait azt' jóvan. Ingyé'... Még az emelt díjas tudakozót vagy a 2x emelt díjas különleges tudakozót sem kellett érte felhívni. Ahelyett, hogy fikáztok, kattogjatok a bannerekre, hogy legyen pént fejleszteni. Uff.

andor 2006.03.12. 20:11:43

NIO tema:
megvizsgaltuk, de ha a szerver egy szimpla socket server, nem hinnem h tudnank channeleket regisztralni hozza es hasonlok, nem? Az NIO klienshez NIO server is kell en ugy gondolom, a C-ben irt memcached-t meg inkabb nem kutyulnenk at

buki92 2006.03.13. 12:55:02

NIO téma: Egy kicsit kavarni tetszik a dolgokat. :-)

A NIO vs. hagyományos I/O nem a kliens-szerver közötti kommunikációban más, hanem abban, ahogyan a JRE kezeli a kommunikációs csatornát.
Valójában a NIO a thread kezelésében más: a hagyományosnál, annyi thread-kell, ahány pending request van, NIO-nál elvileg egy tread-ból ki tudsz szolgálni több ezer request-et. Az egész azért hatákonyabb, mert a thread létrehozás és a thread váltás egy elég drága művelet CPU szempontból, NIO-nál ezt sima függvényhívással helyettesíted.

Maga a TCP/IP protokoll változatlan. Kliens oldalról el sem tudod dönteni, hogy a szerver milyen stílusú socket kezelést használ, és épp ezért nem is érdekes. Tehát fel sem merül, hogy a memcached-t kellene módosítani. Amit módosítani kellene az a kliens-be beépülő Java API a memcache-hez, abban is csak a SockIOPool.java. (Amiben egyébként a NIO-tól függettlenül is vannak elég trehány dolgok. )
Ennek ellenére nem vagyok biztos abban, hogy ez fogja meg a teljesítményt, de van rá esély.

Tényleg, vizsgáltátok már profiler-rel, hogy mennyi idő tölt a végrehajtás a com.danga.MemCached package-ben?

steve 2006.03.15. 21:05:32

Hi!

Ez a memcached-DB kapcsolat nem világos nekem. Valaki legyen szives adjon rá egyértelmű választ. Mit cache-el le az adatbáziból, táblát? Csak mert ha azon update,insert,delete fut, akkor ujra kell cache-elni? És akkor ezt egy daemonnak kéne csinálnia? Meg arrol van itt szó, hogy objektumot cache-el. Egy tábla nem egy objektum. Valaki egy nagyon egyszerű példával megmutathatná miről is szol ez a dolog. Előre is köszi.

Egy másik dolog: Hogy cache-eltek be képeket, html-eket? Olyan dologról nem tudtok hogy a memória egy bizonyos területét meghajtóként megjeleníteni, és amit oda pakolok, azt memből olvasná ki a rendszer?

Att.Att 2006.03.15. 21:35:00

Valaki be tud jutatni a iwiw-be? Előre is köszi.

hdszh · http://hhsdhfsd 2006.04.21. 02:28:46

A statikus tartalmakat (design elemek, style sheet-ek, JavaScript-ek) lighttpd szolgálja ki.
A képek letöltését SQUID proxy-k gyorsítják (accelerator mode-ban), ezek pedig az IMAGE szerveren futó lighttpd-tõl kérik el az adott képet, ha nem találják a saját cache-ükben.
muhahah
mosmar ertem a wiw lassusagat picit
gratulalok bazmeg
baszki
wiw sukc
professzionalisan lassitjak a dolgokat :)