Oldal: 1 / 2 12 UtolsóUtolsó
Eredmény: 1 - 10 (11) összesen

Téma: Nagy latogatottsagu portal fejlesztese

  1. #1
    Rubyist Geri logója
    Csatlakozott
    07-12-15
    Hely
    \x90
    Hozzászólás
    5.605
    Begyűjtött 1.332 köszönetet
    828 hozzászólásával

    Alapbeállítás Nagy latogatottsagu portal fejlesztese

    Ki milyen cache megoldasokat alkalmaz egy olyan oldalnal ahol a varhato latogatoszam esetleg 100-es nagysagrendu?
    a nem tul gyakran frissulo tartalmat nem tul bonyolult cachelni, de mi van peldaul egy forumnal, vagy hasonlo oldalnal ahol a tartalom is folyamatosan valtozik?


    If debugging is the process of removing software bugs, then programming must be the process of putting them in.
    Github Rake tutorial
    Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
    Respect all, fear none

  2. #2
    Bölcs
    Csatlakozott
    07-08-28
    Hozzászólás
    1.024
    Begyűjtött 146 köszönetet
    105 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    Hát igazából erre a lap struktúrája folytán számtalan jó válasz adható.

    Én a livejasmin.com fejlesztési tapasztalata alapján azt mondom, hogy fel kell mérni, hogy milyen arányban történik írás/olvasás a db-be.

    Ez alapján kijön, hogy valószínűleg egy ilyen lapnál mondjuk 10:1 vagy még nagyobb arányban olvasol a dbből tehát a látogatottság növekedésével a mysql replikák igen sokat segíthetnek a kiszolgálásban.

    Így igazából a cache-elés mint olyan másodlagossá válik. Hiszen normál db-ből ki tudod szolgálni a kéréseket.

    Természetesen a 3-ik normál forma itt a db struktúra tervezésekor nem játszik, egy erősen redundáns adattárolásra kell rá állni. Az írás műveletek nehezebbek lesznek, de az olvasáskor jelentkező hatalmas terhelés csökkenés miatt megéri bevállalni.

    Meg nem utolsó sorban ott van a memcache nevű rendszer ami nagyon sokat könnyíthet a db terhein.

    Azonban a lap részletes ismerete nélkül többet mondani nem igazán lehet.



  3. #3
    Rubyist Geri logója
    Csatlakozott
    07-12-15
    Hely
    \x90
    Hozzászólás
    5.605
    Begyűjtött 1.332 köszönetet
    828 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    koszonom.
    igazabol a te valaszodat vartam a legjobban, mert gondoltam hogy a livejasmin -nal szerzett tapasztalatot megosztod velunk.
    a laprol egy kozossegi portalnak keszul, tehat itt is inkabb olvasas lesz a db-bol tobb, es kevesebb iras.
    a redundans adattarolast hogy erted? tobb tablaban is taroljam ugyanazokat az adatokat, vagy tobb db-ben? bar gondolom az elso a megfelelo megoldas.

    a memcache-el a php modulra gondoltal?


    Utoljára módosítva: Geri által : 2008-11-14 11:30

  4. #4
    Bölcs
    Csatlakozott
    07-08-28
    Hozzászólás
    1.024
    Begyűjtött 146 köszönetet
    105 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    Redundáns adat tárolás:
    Fórumokban látványos például:
    - topics tábla: topic neve, sorszáma, létrehozás dátuma
    - posts tábla: postoló neve, topic száma, idő, post tartalma.

    Ez lenne a 3-ik normál forma alak. ekkor ha ki kell iratnod, hogy mikor és ki irt utoljára a táblába akkor a topicok száma + 1 query kell hogy ezt meg tudd tenni. (összes topic listázása, utána minden topichoz egy select a post táblára.)

    Tehát ha tudod, hogy van ilyen igény akkor az elején már igy kezded el tárolni az adatokat:
    - topics tábla: topic neve, sorszáma, létrehozás dátuma, utolsó post dátuma, utolsó post irójának neve.
    - posts tábla: postoló neve, topic száma, idő, post tartalma.

    Igy 1 query -ből ki tudod iratni a szükséges adatokat.

    Ezt értem redundáns adat tárolás alatt. Ez viszont már nem 3-ik normálforma, és csak kis jóindulattal nevezhető 2-ik formának.

    Arra azért figyelj, hogy egy myisam táblába ne tolj pár milliónál több sort, mert nem szereti

    memcache: a php modul mellé jár egy szerver is. Arra van, hogy mondjuk a nagynehezen kiszámitott hosszabb távon jó értékeket belementsd. Tisztán memória alapú, tehát tárolni csak olyan adatot aminek az elvesztése nem fáj (Cache). Ilyen adat lehet például az általános statisztika blokkod adatai. van 12000 felhasználó irtak 184200 postot, eltöltöttek a site-on 1234 évnyi időt, bla bla. Ezt tipikusan sokszor kiiratod, viszont jellemzően nem nagyon változik. Igy akár egy órára is berakhatod a cache-be.



  5. #5
    Rubyist Geri logója
    Csatlakozott
    07-12-15
    Hely
    \x90
    Hozzászólás
    5.605
    Begyűjtött 1.332 köszönetet
    828 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    a memcache ha jol ertelmeztem 2giga memoriat es minel tobb virtualis memoriat igenyel. az adatbazistervezesnel megfogadom a tanacsodat. de felmerult bennem egy kerdes: mennyivel lassabb egy tobb tablas lekerdezes egy egytablasnal, ha az egy queryn belul van?

    ket dolog amirol kivancsi lennek meg a velemenyedre.
    az elso:
    a mysql_query chache hxxp://dev.mysql.com/doc/refman/5.0/en/query-cache.html.
    a masodik:
    hxxp://mysqldatabaseadministration.blogspot.com/2005/11/mysql-5-optimization-and-tuning-guide.html

    es koszonom az eddigieket.



  6. #6
    nimda AlBrown logója
    Csatlakozott
    07-06-15
    Hely
    Budapest
    Hozzászólás
    405
    Begyűjtött 9 köszönetet
    6 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    Arra azért figyelj, hogy egy myisam táblába ne tolj pár milliónál több sort, mert nem szereti
    Ehhez annyi kiegészítést tennék, hogy akkor, ha sok az írási, illetve update művelet, mert MyIsam ilyenkor a teljes táblát lockolja. innoDB viszont row level lockingot alkalmaz így egy udate nem akaszt le mindent . Szóval, ha csak olvasol, akkor nem para a MyIsam.

    Érdemes a statikus tartalmak (kép, video, css.... ) kipakolni egy lighthttpd -re, ne az apache szüttyügjön ezekkel.

    kedvenc blogom, nagy portál tervezése előtt kötelező darab:
    http://www.mysqlperformanceblog.com/
    és ezis kötelező:
    http://developer.yahoo.com/performance/rules.html



  7. #7
    nimda AlBrown logója
    Csatlakozott
    07-06-15
    Hely
    Budapest
    Hozzászólás
    405
    Begyűjtött 9 köszönetet
    6 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    A query cache-el vigyázz! Az esetek nagy többségében nagyon jó szolgálatot tesz, de tipikus példa, amikor egyszerre nagyon sok látogató van a siteon és a sok lekérdezés megy egyedileg. Ami nem feltétlenül kesselhető. Szóval figyelni kell nagyon ilyen queryknél a SQL_NO_CACHE opciókra. Illetve ha sok az írási művelet akkor lassít. Szóval, jó hasznos, de az eredményt mérni és tesztelni kell.



  8. #8
    ingyenfreg mza8202 logója
    Csatlakozott
    07-10-18
    Hely
    Budapest
    Hozzászólás
    167
    Begyűjtött 0 köszönetet
    0 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    Idézet TLoF eredeti hozzászólása Hozzászólás megtekintése
    Redundáns adat tárolás:
    Ez lenne a 3-ik normál forma alak. ekkor ha ki kell iratnod, hogy mikor és ki irt utoljára a táblába akkor a topicok száma + 1 query kell hogy ezt meg tudd tenni. (összes topic listázása, utána minden topichoz egy select a post táblára.)
    nem akarok kotozkodni, de szerintem a cacheles mellett a legfontosabb a jol megirt sql-ek, es jol megvalasztott indexek hasznalata.

    a fentebb irtakat 1 sqlbol is megirhatod, sima join, vagy subselectel. ha ezt valaki plusz queryvel szedi le az eleg nagy problema.

    a redundans adattarolas sem mindig megoldas. valoban vannak olyan esetek, amikor erdemes hasznalni, de en egyaltalan nem ajanlom, hogy mindent osszevissza tarolgasson az ember.

    en nagyon keves helyen hasznalok ilyet, es megis vannak olyan lekerdezeseim, amik tobbmillios rekordsetbol is lefutnak kevesebb mint 1 masodperc alatt. es nem sima sqlrol beszelek, hanem sokszoros joinokrol es subselectekrol.

    peldanak mutatom ezt az oldalt

    nagy terhelesnel is jol vizsgazik, es igaz, cachelve van minden, amit csak lehet. vannak olyan panelek, pl a top10, ami a statisztikabol all elo. na az pl egy durvan eroforras igenyes muvelet lenne, ha nem lenne megtamogatva vagy 8 indexel, es optimalizalt lekerdezessel. igy lefut 1 sec alatt.



  9. #9
    Bölcs
    Csatlakozott
    07-08-28
    Hozzászólás
    1.024
    Begyűjtött 146 köszönetet
    105 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    mza8202: Az egy dolog hogy egy query lefut 1 sec alatt. A másik dolog, hogy közben mekkora terhelést ró az adatbázist kiszolgáló szerverre.

    A jól felépitett redundás adattárolás rengeteget tud segiteni, ha a fejlesztés elejétől, célirányosan tudod alkalmazni / tervezni.

    A subselect / join mint olyan megfelelően alkalmazva, tényleg számos kissebb query összevonására jó lehet, ugyanakkor találkoztam már olyan esettel is, amikor a subselect / join -ok felbontása után 3-4-5 kissebb query futot, a stopper szerint kb 2x annyi ideig, viszont a szerver terhelése 1 alatt volt, mig változatlan látogató szám, és db rekord szám mellett a join-os megoldással 10 fölött volt.

    Ezért mondom mindig azt, hogy a konkrét probléma ismerete nélkül nehéz egy ilyen kérdésre jó választ adni.



  10. #10
    ingyenfreg mza8202 logója
    Csatlakozott
    07-10-18
    Hely
    Budapest
    Hozzászólás
    167
    Begyűjtött 0 köszönetet
    0 hozzászólásával

    Alapbeállítás re: Nagy latogatottsagu portal fejlesztese

    kozel sem mindegy, hogy mit es hogyan joinolsz. es rettentoen fontosak az indexek.
    ha ezek rendben vannak, kicsi a terheles, es a futas ido is.

    de valoban, ha nincs rendesen tamogatva megfelelo indexelessel, a sokszoros joinok igen eroforras igenyesek. epp ezert kell az index

    en is lattam lassu joinolt queryket, amik perces! sebessegel futottak a megfelelo indexelesig, miutan sec alatt lefutottak. tarhely van, az indexekkel nem kell sporolni. csak vigyazni, ne olyat hozz letre, ami keresztbevaghat masnak.

    a sok adatbazishivas is megterhelo tud lenni, mind a webszervernek, es az adatbazisszervernek is (kapcsolatepites, a kom letesites, stb..stb.). annal jobb szerintem, minel kevesebb nyulsz ki dbbe, minnel kevesebb parhuzamos kapcsolat fut egyszerre.

    Ezért mondom mindig azt, hogy a konkrét probléma ismerete nélkül nehéz egy ilyen kérdésre jó választ adni.
    ebben tokeletesen egyetertunk


    Utoljára módosítva: mza8202 által : 2008-12-17 00:25

Oldal: 1 / 2 12 UtolsóUtolsó

A téma címkéi:

Könyvjelzők

Hozzászólás szabályai

  • Új témákat nem hozhatsz létre
  • Válaszokat nem küldhetsz
  • Fájlokat nem csatolhatsz
  • A hozzászólásaidat nem módosíthatod
  •