Nagy látogatottságú PHP portál tippek
2010-09-27T11:54:34+02:00
2013-04-01T13:21:51+02:00
2022-06-29T08:45:38+02:00
  • Sziasztok!
    Gondoltam nem nyitok új topicot, mert szerintem ide tartozik a kérdésem: Másik táblákból számított mezőt kéne felvennem MS SQL-ben, de mivel gyakran kéne az értéke, gondolkoztam, hogy jobb lenne-e, ha egy valóban új mezőt raknék az érintett táblába, vagy elég hatékony lenne az is, ha indexelt view-t használnék???
    Sokszor nem változna az értéke, de mint mondtam, annál többször kérdezném le...
    Mutasd a teljes hozzászólást!
  • egy nem-materializált view használata legfeljebb csak ugyanolyan hatásos lehet (...)


    Egy jól megírt (expandable) view használata _pontosan_ ugyanolyan hatásos mint a befoglalt SQL állandó kopipésztelése.
    És a kopipésztet nem szeressük.

    Az pedig, hogy MySQL adatbázisban nem lehet materializált view-kat definiálni, valóban kedvezőtlen pozíciót eredményez a MySQL-nek az adatbázis-kezelők rangsorában.

    Mutasd a teljes hozzászólást!
  • Konkrétan MS SQL esetén nem csak hogy nem "halálos bűn", hanem kifejezetten célszerű view-kat használni. Ha a view-t használod egy-egy query-ben ill. tárolteljárásban, akkor az execution plan-ben a view maga nem fog szerepelni, hanem makrószerűen bele lesz ágyazva az execution plan-be a view tartalma.

    Ebből abszolút nem következik, hogy célszerűbb a view használata. Sőt, teljesen nyilvánvaló, hogy egy nem-materializált view használata legfeljebb csak ugyanolyan hatásos lehet, de egy rajt végzett lekérdezés gyorsabban biztosan nem hajtódhat végre, mint egy magán a view-n végezni kívántból + a view összeállításához használtból derivált implicit SELECT.

    Amiről itt beszéltünk az ráadásul az SQL Server által "indexelt"-nek (indexed view), az Oracle által pedig "materializált"-nak (materialized view) hívott view-k használata volt, amelyek nem kvázi makróként jelennek meg és nem kerülnek kifejtésre a hivatkozás helyén a tárolt eljárásokban, azon egyszerű oknál fogva, hogy ezek valójában redundánsan és ténylegesen létrehozott és vezetett adathalmazok (kvázi táblák, amelyek adattartalma azonban közvetlenül nem manipulálható, és automatikusan frissül a forrástáblák alapján). A lekérdezés csakis ezekből lehet potenciálisan - bizonyos feltételek teljesülése esetén - gyorsabb, mint egy csak logikailag létező (nem materializált, hanem "makrószerű"), az adataid futásidőben a forrástáblákból összeválogató view-n végrehajtott SELECT.

    Tehát a materializált view-kat nem támogató adatbáziskezelők (MySQL, PostgreSQL, stb.) esetében a view-k használatának egyetlen előnye az egyszerűbb programozási szerkezetek, a denormalizált struktúrák ill. - mezőszintű hozzáférésszabályozás hiányában - az adatokhoz történő hozzáférés körének egyszerű korlátozása* jelentheti, de sebességben biztosan nem jelenthet semmilyen előnyt, sőt, tipikusan erősen lassítja a feldolgozást, főleg ha egymásra is építi, halmozza őket az ember (cascaded view). Ebből eredően nagyforgalmú oldalak esetében igenis gyakorlatilag mindig halálos bűn az alkalmazásuk.

    * ti. az eredeti táblákból különböző részhalmazokat leválogató view-kkal és az eredeti táblához történő hozzáférés tiltásával biztosíthatod, hogy a különböző szerepkörű felhasználók mindig csak a feladataikhoz feltétlenül szükséges adatokat lássák az összes tárolt adatból, anélkül, hogy valóban külön táblákba kellene ezeket az összetartozó adatokat szétdobnod, vagy hogy mezőszinten kellene tudnod szabályozni a hozzáférési jogokat


    Ez alapján a leírás alapján MySQL-ben a MERGE algoritmussal definiált view-kat a szerver makrószerűen értelmezi, akár csak más "komoly adatbáziskezelők".

    Mint írtam, a komoly adatbáziskezelők esetében emlegetett funkció a materializált, redundánsan tárolt view volt, ami pont ellentetje a makrószerűen értelmezett view-nek. Ezt a MySQL nem tudja, de még a PostgreSQL sem (ami pedig igen sok komoly SQL szerkezetet támogat, az egyébként ebből a szempontból viccnek tekinthető MySQL-hez képest).
    Mutasd a teljes hozzászólást!
  • For MERGE, the text of a statement that refers to the view and the view definition are merged such that parts of the view definition replace corresponding parts of the statement.


    MySQL :: MySQL 5.0 Reference Manual :: 18.4.2 View Processing Algorithms

    Ez alapján a leírás alapján MySQL-ben a MERGE algoritmussal definiált view-kat a szerver makrószerűen értelmezi, akár csak más "komoly adatbáziskezelők".
    Mutasd a teljes hozzászólást!
  • Konkrétan MS SQL esetén nem csak hogy nem "halálos bűn", hanem kifejezetten célszerű view-kat használni.

    Ha a view-t használod egy-egy query-ben ill. tárolteljárásban, akkor az execution plan-ben a view maga nem fog szerepelni, hanem makrószerűen bele lesz ágyazva az execution plan-be a view tartalma.

    Ugyanez igaz MS SQL esetén az ún. inline-table UDF-ekre is.

    Mutasd a teljes hozzászólást!
  • Értem, köszönöm.
    Mutasd a teljes hozzászólást!
  • Végülis lehet úgy fogalmazni, hogy a (nem materializált) View tulajdonképpen nem más mint egy eszköz a kódújrafelhasználásra SQL lekérdezések esetén. Vagyis ugyanarról van szó, mint amikor egy procedurális nyelven kiszervezel egy gyakran használt pattern-t egy eljárásba. Alapvetően ez jó gyakorlat de nagyon performancia szenzitív kódnál már felülvizsgálandó.
    Mutasd a teljes hozzászólást!
  • Ha már szóba jöttek az adatbázisok, a View-okról mi a véleményed? Én úgy hallottam, hogy nagyon megéri használni őket

    A nagyterhelésű oldalakon és egyszerűbb adatbáziskezelőknél biztosan nem. Ezek ugyanis a view-kat nem párhuzamosan vezetik redundáns táblákként a forrástáblákkal, hanem a forrásadatok alapján minden hozzáféréskor élőben generálják le, gyakorlatilag egy előre rögzített SELECT transzparens végrehajtásával. Pl. a MySQL csak utóbbit tudja - ez gyakorlatilag teljesen használhatatlan megoldás teljesítmény szempontjából, hiszen óriási overheadet jelent a folyamatos újraépítés miatt. Komolyabb adatbáziskezelők mint pl. az Oracle vagy a MSSQL tudják a párhuzamos vezetést is (ti. amikor a view adattartalma maga is tárolásra kerül, redundáns módon az adatbázison belül, és ha új sor kerül a forrástábláiba, vagy valamelyik beválogatott mezője módosításra kerül azokban, akkor a view megfelelő sorának adattartalma is automatikusan frissül) - ami ugyan módosításoknál szintén jelent némi overheadet, de legalább lekérdezéseknél nem, sőt, ha sok táblából van összeválogatva a view, akkor akár még gyorsabb is lehet a működése ezen a módon, mint ha egy VIEW létrehozásakor használttal ekvivalens SELECT-et kellene a DBMS-nek lefuttatni minden eléréskor. De ahhoz, hogy ez kifizetődő legyen igen jó arányban kell lenniük a módosítási és lekérdezési műveleteknek (ti. nagyon sok lekérdezésre kell nagyon kevés módosításnak jutnia).

    Szóval alapvetően a view-k használata is a halálos bűnök közé tartozik a nagyforgalmú oldalak esetén, nagyon speciális eseteket leszámítva - és azokban is csak akkor opció, ha igen komoly adatbáziskezelőnk van. A MySQL nyilvánvalóan nem az, de még a PostgreSQL sem; legfeljebb Oracle, MSSQL használata esetén lehet egyáltalán akár csak megfontolás tárgya is a view-k használata.
    Mutasd a teljes hozzászólást!
  • A kötegelt feldolgozással nem tudom, mennyire tudsz tökéletesen online maradni (sztem biztos nem).

    Miér értesz "online maradás" alatt? És szerinted ez miért lenne problémás kötegelt feldolgozásnál?

    A frontend és backend elszeparálása adatvesztéssel járhat programhiba esetén. Bár ez erre a problémára úgysem megoldás.

    Ezt sem tudom honnan vetted. Semmifél adatvesztéssel nem jár a frontend és a backend szeparálása. Főleg, hogy ez egy architektúrális szétválasztás - a backend és a frontend akár egy programban is lehet (bár legtöbbször ez nem praktikus).

    Backofficeról nem volt szó.

    Kevered a szezont a fazonnal. Backendről volt szó, aminek semmi köze nincs a backoffice-hoz.

    Az egyedi kulcsok alkalmazása esetén is egymásra futhatsz, ha az egyedi kulcsokat tartalmazó tábládat (azaz hogy van-e elindított ugyanolyan feldolgozás és ha nem, most elindulsz vele) nem lockolod le legalább ebbe a táblába történő selected és ha kell, inserted idejére.

    Persze ez sem igaz. Semmilyen lockolásra nincs szükség - csak a tranzakciók és az egyedi kulcsok támogatására az adatbázis részéről.

    A módszer lényege röviden az, hogy minden egymást kölcsönösen kizárni kívánt feldolgozási folyamat megkezdésekor nyitsz egy tranzakciót, amiben generálsz egy új - szigorúan monoton növekvő - egyedi kulcsot az egyedi táblába, amit oda - a tranzakció részeként - beszúrsz, majd tetszőleges további módosítási, beszúrási műveleteket hajtasz végre (ez utóbbiak lesznek a lényegi feldolgozás), amik befejezése után megpróbálod lezárni a tranzakciót. Ez (az egyedi kulcs miatt) csakis akkor sikerülhet neked ha ezzel a folyamattal párhuzamosan nem indult vagy folyt még egy ugyanilyen - ugyanabba az egyedi kulcsos táblába dolgozó - folyamat, ami előbb véget is ért ennél a feldolgozásnál. Ha a második feldolgozási folyamat ugyan már elkezdődött, párhuzamosan futott a jelen feldolgozással, de nem ő ért előbb véget, nem lesz gond, mert ő már nem fogja tudni a tranzakcióját lezárni (az ütköző egyedi kulcs miatt); ha pedig ő fejeződött be előbb (és sikeresen lezárta a tranzakciót), akkor pedig a most szóban forgó tranzakció fog elhasalni. Ha esetleg utóbbi eset azzal egészül ki, hogy ha azután mielőtt a korábban befejeződött (sikeres) feldolgozás lezárult, de még mielőtt az aktuális (ilyenkor már bukásra ítélt) feldolgozás befejeződött volna elkezdődik egy harmadik feldolgozás (ami így párhuzamosan fut majd az aktuális feldolgozással), az nem gond, mert jelen feldolgozás úgyis megbukik majd - így a harmadik feldolgozás akár sikeres is lehet. A lényeg, hogy a két időben egymást részben vagy teljesen átfedő feldolgozás közül mindig csak az egyik eredménye kerül majd tárolásra az adatbázisban. Garantáltan.

    Ha a párhuzamos feldolgozási folyamatok közül bármelyik (vagy mindegyik) egyéb hiba miatt megszakad, akkor sincs gond, hiszen annak a tranzakciója automatikusan törlésre kerül az adatbáziskezelő által. Ráadásul az egyedi kulcshalmazt tetszőleges elemekkel (pl. IP cím, felhasználó azonosítója, stb.) bővítve elérheted, hogy csak az egymással valóban összefüggő (ti. ugyanarról az IP-ről, ugyanattól a felhasználótól, stb. érkező) feldolgozások zárják ki kölcsönösen egymás sikeres lefutását, de pl. a két különböző felhasználóhoz kapcsoló feldolgozó folyamat simán lefuthasson párhuzamosan is sikeresen. Mindenfajta lock nélkül.

    Ennek a megoldásnak az egyetlen hátránya, hogy - mint korábban írtam - erősen szuboptimális, hiszen bár garantálja a konkurenciahelyzetekből adódó adatsérülések vagy -duplikációk elkerülését, viszont potenciálisan feleslegesen veszteget időt és erőforrást a feldolgozásra - hiszen csak a feldolgozási folyamat végén, a tranzakció lezárásakor derül ki, hogy sikeres volt -e a végrehajtás egésze vagy sem. Ráadásul ha nem volt sikeres, akkor meg kell tudni állapítani, hogy ez a párhuzamosságot kizáró egyedi kulcs ütközése, vagy más adathiba miatt volt -e, és ettől függővé tenni az esetleges automatikus újrapróbálkozást (ami viszont potenciálisan megint elbukhat egy versenyhezten). Az ideális megoldás ezért - ahogy szintén megírtam az előbb - a sor alapú feldolgozás, ahol a beérkező, egymással potenciálisan konfliktusba kerülő kéréseket egy várakozási sorba állítva, és szigorúan egymás után hajtjuk végre őket. Ez egyrészt garantálja, hogy nem pazarlunk erőforrásokat a konkurenciahelyzet miatt biztosan elbukó feldolgozására, másrészt azt is, hogy záros időn belül minden a sorba került elem feldolgozásra kerül (nem húzodhat el a végtelenségig az adott elem feldolgozása az esetleges folyamatos ütközések miatt). Ezen kívül a sor figyelésével az esetlegesen biztosan konfliktust okozó (pl. az F5 nyomogatásából eredő) kéréseket azonnal visszautasíthatjuk. De ehhez külön kell választani a frontend és a backend logikát.
    Mutasd a teljes hozzászólást!
  • Ha már szóba jöttek az adatbázisok, a View-okról mi a véleményed?
    Én úgy hallottam, hogy nagyon megéri használni őket, és csodálkozom, hogy eddig nem jöttek szóba itt...
    Mutasd a teljes hozzászólást!
  • A kötegelt feldolgozással nem tudom, mennyire tudsz tökéletesen online maradni (sztem biztos nem).

    A frontend és backend elszeparálása adatvesztéssel járhat programhiba esetén. Bár ez erre a problémára úgysem megoldás. Backofficeról nem volt szó.

    Az egyedi kulcsok alkalmazása esetén is egymásra futhatsz, ha az egyedi kulcsokat tartalmazó tábládat (azaz hogy van-e elindított ugyanolyan feldolgozás és ha nem, most elindulsz vele) nem lockolod le legalább ebbe a táblába történő selected és ha kell, inserted idejére. Tehát megint egy lock. (Mondjuk ez még nem vészes, ha a biztonság fontosabb, mint az egyszerűbb, gyorsabb, de kockázatosabb session-ös megoldás.)
    Mutasd a teljes hozzászólást!
  • Az előbb írtam le. Ideálisan többrétegű architektúrával, sor-alapú feldolgozással. Akár PHP-ben is; bár azt is írtam, hogy ha az embernek fontosak ezek a dolgok, akkor eleve nem PHP-ban írja meg legalább a backend rendszert, mert az alapvetően nem erre van tervezve, és ennek megfelelően alkalmatlan is olyan feladatok megoldására, ahol fontos a definiált kilépési utak megőrzése, a hibák, kivételek kezelésének lehetősége, erőforrások felszabadításának biztosítása minden körülmények között, stb.

    De ha mindenképpen ragaszkodik valaki a PHP-hez akkor is legrosszabb esetben pusztán egy megfelelő adatbáziskezelővel (=értsd nem MySQL-lel, pláne nem MyISAM motorral), pusztán tranzakciók és egyedi kulcsok alkalmazásával is tökéletesen kizárható, hogy két feldolgozás egymásra futhasson; bár ez önmagában mindenképpen szuboptimális megoldás, még ha garantáltan biztos is.

    A táblaszintű zárat és hasonló szörnyűségeket mindenesetre el lehet felejteni, akárcsak a "gyorsan (és esetleg gyakran) elmentem" módszert is, mert ez valójában nem zárja ki az adatintegritást veszélyeztető konkurenciahelyzetek bekövetkezését, csak az előfordulásuk esélyét csökkenti.
    Mutasd a teljes hozzászólást!
  • ha valóban védelem szükséges a dupla tranzakció és a session-trashing ellen, akkor az teljesen másként kell megoldani

    hogyan? (php-s szerveren)
    Mutasd a teljes hozzászólást!
  • Ha a pizza helyett valami pénzügyi instrumentumról lenne szó, akkor a probléma már elég nagy is lehetne. Például nem mindegy, hogy 1000 vagy 2000 vagy még több részvényt veszel vagy adsz el így tudtod nélkül, véletlenül.

    Ilyen rendszert nem is PHP-ben ír meg épeszű ember. Tranzakciókezelésről és többrétegű (szeparált backend és frontend) architektúrákról, sor/köteg-alapú feldolgozásról már nem is beszélve, amelyekkel tökéletesen kizárhatóak az ilyen problémák már architektúrális szinten. Amit már csak azért is így csinál meg az ember, mert az a nyamvadt frontend program bárhol végzetesen is elszállhat, timeouttól, terheléstől és F5 nyomogatástól függetlenül is, akár az állapotmentő rutinokban is. És akkor ugyanúgy meg vagy lőve, hogy ti. definiálatlan ill. inkonzisztens adatállapotba kerül a session, ami többek között dupla ill. elveszett tranzakciókhoz is vezethet.

    A refresh nyomogatásra és ezzel összefüggésben a duplikált tranzakciók elleni védelemre is egyébként teljesen barkács módszer ez az "azonnali session mentés", mert ez valójában nem akadályozza meg ezen problémák keletkezését, csak csökkenti azok véletlen előfordulásának esélyét. De pl. ha direkt erre játszom, akkor még mindig könnyűszerrel át tudom verni ezt a fajta "védelmet" a szerver célzott túlterhelésével, belassításával. Szóval egyezzünk meg abban, hogy ez gyakorlatilag nem véd semmi ilyesmi ellen - ha valóban védelem szükséges a dupla tranzakció és a session-trashing ellen, akkor az teljesen másként kell megoldani.
    Mutasd a teljes hozzászólást!
  • Ha már a lock-ról volt szó. Az elburjánzott direkt beírt tábla lock sql utasítások is elég könnyen gallyra tudják vágni az adatbázist (főleg, ha az unlock utána le sem fut valamiért). Igazából, ha nem valami szigorú számadású sorszám kiosztásáról van szó, szinte szükségtelen olyat írni valaha is.
    Mutasd a teljes hozzászólást!
  • Az ignorálás itt arra vonatkozik, hogy akárhogyis van beállítva a szerver, a php script, azaz a mentés része mindenképpen lefusson, mégha a user be is zárta a böngészőt.

    A session azonnali mentése pedig egy tipikus refresh elleni védelem. Ugyanis ha az adatbázis belassulna, akkor a mentés résznél várna a php script a befejezésre (eközben ugye már az adatbázis szerveren állnak sorban az sql kérések, amik valamikor majd lefutnak). Közben a user akár meg is nyomhathja az F5-öt. Ekkor a védelem még le se futna, ha a fájl végére tennénk. Ugyanis a session fájlba írása nem történne meg még ekkorra.

    Ha a pizza helyett valami pénzügyi instrumentumról lenne szó, akkor a probléma már elég nagy is lehetne. Például nem mindegy, hogy 1000 vagy 2000 vagy még több részvényt veszel vagy adsz el így tudtod nélkül, véletlenül.
    Mutasd a teljes hozzászólást!
  • Ez valami lock szerű dolog. Szal beteszed session-be, hogy éppen dolgozik a rendszer, aztán ha már megcsinálta a melót, akkor feloldod a lockot, addig meg ignorálod az összes kérést ami arra a feladatra vonatkozik?
    Mutasd a teljes hozzászólást!
  • Ha adatbázis túlterhelés lép fel, és az oldalból a felhasználók sokáig fehér képernyőt látnak, megijednek, és hajlamosak rátenyerelni az F5 gombra, és nyomkodják, ameddig el nem fárad a kezük. Ekkor előfordulhat, hogy a kívánt 1 családi pizza helyett 5-öt hoz a futár (mivel az ez elleni védelem még nem mentődött el). Erre az esetre felkészülve ez is alkalmazható:

    <?php session_start(); if ($_SESSION['kosar_lementve'] !== true) { ignore_user_abort(); $_SESSION['kosar_lementve'] = true; session_write_close(); session_start(); // Mentés: // ... // Kiürítjük a kosarat: unset($_SESSION['kosar']); } echo "Köszönjük, megrendelését fogadta a rendszerünk! "; echo "Aktuális akciónk keretében, a megrendelt pizzához, ingyen üdítőitallal kedveskedünk. "; echo "A pizza mellé, szalvétába csomagolva."; ?>
    Mutasd a teljes hozzászólást!
  • Néha szükséges lehet a session azonnali lementése (session_write_close) még a script lefutása előtt.

    Tudnál erre példát mondani?
    Mutasd a teljes hozzászólást!
  • Az adatbázis kapcsolatra készülj fel már most egy olyan factory-val, amely alkalmas arra, hogy bizonyos moduljaidat bármikor egy másik adatbázis szerverre átszervezhesd.

    Néha szükséges lehet a session azonnali lementése (session_write_close) még a script lefutása előtt.

    Néha ki kell kényszeríteni, hogy a script mindenképpen lefusson, mondjuk adatmentésnél, mégha a user valamiért be is zárta volna az oldalt (ignore_user_abort). Például, mert a lassulás következményeként feladta.
    Mutasd a teljes hozzászólást!
  • Köszönöm a tanácsokat, kezdetnek nagyon jó alapot adnak, hogy mire figyeljek oda, ill. milyen téren fejlesszem a tudásom tovább.
    Mutasd a teljes hozzászólást!
  • A keretrendszerek úgy vannak kitalálva, hogy nagy látogatószámnál is használhatóak legyenek. Lehet, hogy gyorsabb is lesz, mint ha saját magad írnád a CMS-t.

    Az adatbázis indexelése, a felesleges lekérdezések, esetleg a feleslegesen futó AJAX-os adatbázis kapcsolatok (pl. tizedmásodpercenként frissítesz egy adatot az adatbázisból, pedig elég lenne másodpercenként is) szokták lassítani az oldalt.
    Mutasd a teljes hozzászólást!
  • Valamennyit lassít, de nem azon fog elvérezni az oldalad. Általában az adatbázis szokott lenni a szűk keresztmetszet.
    Mutasd a teljes hozzászólást!
  • Ejj ez nagyon hasznos leírás számomra is.
    Hasonló cipőben járok mint a topiknyitó kolléga, de elképzelhető, hogy hamarosan lesz egy projekt aminek nagyobb látogatottsága lesz, és többnyelvű megjelenítés kell.

    Az eddigi projektjeimben gyakran smarty-t használtam.
    Mit gondoltok, nagyobb látogatottságú oldalaknál mennyire érdemes ezt használni? Úgyértem mennyiben lassítja vajon a futást?
    Mutasd a teljes hozzászólást!
  • Szép hosszú hozzászólás, úgyhogy nem is maradt időm most elolvasni, majd csak este, ha újra gép előtt leszek.

    A tartalomtól függetlenül nagyon szépen köszönöm a tippeket, este átrágom magam rajtuk.
    Mutasd a teljes hozzászólást!
  • Pár tipp:
    - profiláld a kódod, és javíts a futási sebességen ahol lehet; ez nagyforgalmú oldalaknál azért különösen fontos, hiszen az elvesztegetett idő halmozódik, a válaszidő pedig a konkurenciahelyzetek miatt exponenciális arányban nő a párhuzamos felhasználószám növekedésével, tehát igen fontos, hogy a szkripjeid olyan kevés ideig fussanak, amennyire csak lehet (ezáltal csökkentve a konkurenciahelyzetek számát). tehát pl. 10%-os átlagos futásidő-csökkenés az egyes szkriptek vonatkozásában 20-40%-kal is növelheti a kiszolgálás effektív átlagos sebességét nagy látogatószám mellett
    - gyorstárazz mindent amit lehet (a teljes oldalas gyorstár a legjobb, de ha különböző oldalakon is ugyanazt a tartalmi blokkot jeleníted meg, azt is érdemes gyorstárazni, és ilyen gyorstárazott blokkokból felépíteni a teljes oldalt "dinamikusan")
    - memcached-et lokális gépen felejtsd el, mert lassú; apc, xcache és társai a barátaid amíg csak egy szervered van, ill. amíg a szerverek között nem kell a gyorstár tartalmát megosztani
    - lépésenként építsd fel az oldalad, azaz ne először lekérdezz minden adatot és aztán jelenítsd meg, hanem amint megvan az adat nyomd ki a kimenetre és flushold (ez egyben azt is jelenti, hogy az ilyent nem támogató - pl. egyes MVC - frameworkök nem ideálisak). ez azért fontos, mert így ha az oldalad legenerálása több mp-ig tart, akkor is viszonylag gyorsan tudsz már valamit a felhasználónak prezentálni (akkor is ha az oldal többi része késik), és így ő gyorsabbnak érzékeli majd a működést.
    - használd az Expires, ETag, stb. HTTP fejléceket, hogy megspórold a változatlan tartalmak újbóli és újbóli letöltését (statikus tartalmakra, mint pl. képek és CSS az Apache ExpiresByType direktíváját is használhatod)
    - tömörítve (gzip) szolgáld ki a tartalmakat! különösen a statikus CSS és JS fájlokat, de maguk az oldalak tömörítése is jó ötlet ha gyakran letöltött, gyorstárazott oldalról van szó; ha nem, akkor nem érdemes, mert nem nyersz vele semmit (ti. mert a tömörítés legalább annyival megnöveli a teljes oldalgenerálási időt, mint amennyivel gyorsabban a tömörített változatot át tudod passzírozni a kábelen).
    - ha MySQL-t használsz, akkor a gyakran írt táblák InnoDB-k legyenek, ne MyISAM-ok, mert míg utóbbi módosítása (insert, update) a teljes tábla zárolásával jár, az InnoDB-k esetén sorszintű zárolás van, ami csökkenti a párhuzamos műveletek végrehajtásának idejét ha nem ugyanarra a sorra vonatkoznak
    - a szinte csak olvasott táblákra rakj annyi indexet amennyit csak elbírnak (és értelmes, a lekérdezesekben alkalmazott szűrésekhez), a gyakran írt táblákon viszont minimalizáld az indexek számát, vagy ha igen ritkán kell lekérdezést futtatni azokon, akkor akár el is hagyhatod (esetleg a lekérdezés idejére hozod csak létre, aztán eldobod, pl. napi statisztikák készítéséhez)
    - ha nagyon gyakran kellene ugyanazt a sort módosítani az adatbázisban, aminek viszont nem kell teljesen élőnek lennie (pl. egy cikk olvasottsági számlálóját, a napi egyedi látogatók számát a statisztika táblában, stb.), akkor próbáld úgy módosítani a működést, hogy UPDATE helyett inkább INSERT-eket használj egy másik, átmeneti táblában, amelyből aztán periódikusan (pl. percenként v. 5 percenként) átfejted az INSERT-ekben logolt módosítások összesített ill. végeredményét egyetlen UPDATE-tel az élő táblába; ez megint csökkenti azt az időt, amikor a kiszolgáló szálak egymást blokkolják (mert az INSERTek - főleg ha DELAYED-ek - InnoDB táblában párhuzamosan is mehetnek, míg az ugyanarra a sorra vonatkozó UPDATE-ek értelemszerűen kénytelenek egymást bevárni).
    - rendszeresen építtesd újra az adabáziskezelővel az indexeket (OPTIMIZE TABLE, ANALYZE, és társai, attól függően milyen adatbáziskezelőt használsz), mert a sok UPDATE és INSERT után általában már nem sikerül nekik ideálisan súlyozni azokat, az újraépítés során viszont optimális fát hoznak létre, amin sokkal gyorsabbak lehetnek a lekérdezések
    - az Apache vagy saját logfájlokat naponta, hetente rotáld és archiváld (tömörítsd), mert a legritkább esetben van szükség a visszanézésükre, így nagyrészt feleslegesen foglalnak helyet, viszont minél nagyobbak, annál lassabb lesz a logolás (függetlenül attól, hogy persze append esetén mindjárt a végükre pozícionálsz)
    - defragmentáld napi, vagy maximum heti gyakorisággal a fájlrendszert! igen, Linuxon is, mert a naplóállományaid és a gyakran bővített tábláid rommá lesznek fragmentálódva egy idő után
    - rakj sok memóriát és gyors vinyókat a gépbe! ezek általában fontosabbak, mint az erős CPU
    - CPU-ból inkább lassabb, de többmagosabb változatot használj, mert utóbbi fontosabb a több felhasználó párhuzamos kiszolgálása szempontjából, mint az abszolút sebesség!
    - vagy kapcsold ki teljesen a névfeloldást a logolás vonatkozásában, vagy futass helyi DNS szervert és a névfeloldást azon keresztül végezd, mert egyébként nagyon belassulhat a kiszolgálás nem a terhelés, hanem pusztán a névfeloldás lassúsága miatt!
    Mutasd a teljes hozzászólást!
  • Sziasztok !

    Elég sok bemutatkozó oldalt készítettem már, jó pár webáruházat, de ezeket egyszerre legfeljebb 100 ember, ha látogatja egyszerre.

    Felmerült a kérdés bennem, hogy nagy látogatottságú portál készítése esetén (amit mondjuk egyszerre pár ezer felhasználó használ) mire kell figyelni, mi az, amit másképpen kell teljesen csinálni, mint egy kis látogatottságú oldal esetén stb. (gondolok itt memcached-re, különböző optimalizációkra stb.) ?

    Van-e eseteleg valakinek olyan leírása, linkje, ahol tippeket olvashatnék, tanácsokat, esetleg valakinek személyes tapasztalata ?


    Üdv
    Mutasd a teljes hozzászólást!
abcd