Weboldal optimalizálás, gyorsítás (PHP, MySQL)
2006-11-25T18:11:05+01:00
2010-07-23T13:03:51+02:00
2022-07-25T01:22:34+02:00

  • Since we’ve made all these changes, we have been able to scale memcached to handle 200,000 UDP requests per second with an average latency of 173 microseconds. The total throughput achieved is 300,000 UDP requests/s, but the latency at that request rate is too high to be useful in our system. This is an amazing increase from 50,000 UDP requests/s using the stock version of Linux and memcached.


    Ez az érdekes, 50 ezerről 300 -ra tolták fel a req/sec -et.

    Bár ez tényleg csak az érdekesség kategória, nem hiszem, hogy sok olyan ember járt már a prog.hu -n, akinek szüksége lett volna ennek a limitnek a megemelésére.

    De ha valakit mégis érdekelne, ott van a kommnetek közt a github-os link, ahonnan letölthető a memcache FB átirata.
    Mutasd a teljes hozzászólást!
  • omg tenyleg :D jo késő van már :P
    Mutasd a teljes hozzászólást!
  • Gugli, "facebook memcached"..?
    Mutasd a teljes hozzászólást!
  • 'Érdemes még olvasgatni a facebook blogjában, hogy ők mit alkottak a memcache-el. '

    pontosan merre keressem ezt? :D
    Mutasd a teljes hozzászólást!
  • A mysql táblákat is cachelheted. Azt csak be kell kapcsolni. Elég jól manageli magát, mert amíg nem nyúlsz a táblához, addig a memóriából szedi az adatokat és módosítás után is csak az a tábla (vagy annak része) kerül ki a cache-ből, ami változott. Nálam van egy oldal, amin nagyon sok és elég időigényes lekérdezések futnak, ezért először olyan 30 másodpercen túl jön be az oldal. Másodszorra már 1-2 másodperc alatt. Szerintem a memcache se csinál mást, csak azt neked kell karbantartanod. Ez több szerver és egy adatbázis szerver esetén már nem is olyan egyszerű.

    De általában egy normálisan megtervezett adatbázis esetén a lekérdezések többsége valami index alapján egyetlen táblában keres. Egy lekérdezés tart mondjuk 0,01-0,001 ms ideig. Mondjuk fusson le egy húzósabb oldalon olyan 30, akkor átlag olyan 0,15 ms az adatbázisban történő turkálás ideje. Egyszerre mondjuk 4-5 ember esetén már eltarthat 0,5-1 másodpercig is. De ügye ilyenre egy nem kiemelkedően magas látogatottságú oldalon 0% esély van. Ez legyen akkor probléma, ha már nagyon sok egyedi látogatód van. Addig az olyan eseteket kell elkerülni, mint amivel a múltkor találkoztam, hogy egy főoldalon (home page) 4000 query fut le. Az oldal betöltési ideje meg bőven 30 másodperc felett járt. Csoda?

    Egyébként sok múlik a webszerver beállításain is. Például a javascriptek, képek, css fájlok betöltése mehet a böngésző gyorsító tárából is (htaccess). A jquery és egyéb keretrendszerek meg mehetnek a google oldaláról is, levéve a terhet a szerveredről. Ezekről is neked kell/érdemes gondoskodnod.
    Mutasd a teljes hozzászólást!
  • memcache:
    Én alapvetően MVC modellben dolgozok, vannak osztályok, amik adatbázisból adatokat adnak vissza, bele írnak, stb., controllerek a user ügyködéseinek lekezelésére, meg view, ami a html-t generálja.
    A View részhez tökéletes pl. a smarty cache, a control-on szinte nincs mit cachelni, marad tehát a model rész.
    Magyarán az adatbázisból megkapott adatokat cachelem, hogy pontosan hogyan, azt az alkalmazás jellege dönti el.
    Van, hogy a függvény teljes visszatérési értékét érdemes cachelni, van hogy csak egy belső részét. Ezt leginkább az határozza meg, hogy változás esetén milyen cache-t kell eldobni.

    Mondok egy példát:
    function getLegtökösebbUserek()
    {
    if (megvan cache-ben) return cache adat;
    select from userek order by tökös desc limit 10
    mentés cachebe(teljes sql által visszaadott rekord halmaz);
    return sql-ből jövő adat;
    }

    itt egy cache elemként tárolhatod a 10 usert, viszont ha valamelyikőjök módosítja mondjuk a nevét, akkor
    a, eldobod az egész cache-t
    b, a cache bizonyos részét módosítod

    vagy ha a userek adatait sok más helyen is használod, akkor azokat egyenként cache-be rakod:
    memcache->set("user_data_" . $userid);
    és a getLegtökösebbUserek() -ben csak a userid-kat cacheled, majd hozzá sok másik cache-ből olvasod az adatokat.

    ===================

    mysql memcache:
    létezik olyan megoldás, amivel a memcache függvényeit mysql-ben használhatod:
    SELECT * FROM user WHERE user_id = memcache_get('aTökösCsávóUserIDja');

    de akár az egész adatbázist replikálhatod memcache-be, minden táblára minden insert, update, delete eseményre írsz egy triggert, ami memcache-be menti az adatot. Nem biztos, hogy ér annyit, mint amennyi küszködés van vele.


    mennyi a valoszinusege hogy ha egy adattablat cachelek, akkro az valami hiba folytan elveszik az eterben, es a modositasok eltunnek

    100%
    na jó, nem, de cache-ben soha ne tárolj olyan adatot, ami nincs meg máshol. A cache az cache, vagy a magyar neve talán beszédesebb: gyorsítótár. Magyarán ha törlöm a cache-t, max lassabb lehet az alkalmazásod, de ugyanazt a funkciót kell ellátnia. Mindent, amit cache-be raksz, tárolni kell perzisztens tárolóban is (pl sql).

    ===========

    Ja, csak egy érdekesség: mikor először hallottam a memcache-ről, már futott egy oldal, ami kezdett dögledezni az sql terheléstől. Kb. egy hét alatt belepakolásztam mindenfelé cachelést, majd ezek publikálása után kb 10-edére esett a szerver terhelése :) Előtte volt olyan oldal, ami 4-6 mp alatt generálódott, utána leesett 100 ms-ra :D
    Szóval ha az ember jól használja, nagyon sokat tud segíteni.

    Érdemes még olvasgatni a facebook blogjában, hogy ők mit alkottak a memcache-el.
    Mutasd a teljes hozzászólást!
  • Én hoztam fel a témát.


    Igen, inkább az oldalgenerálási idő érdekelne, mivel a többi idő eléggé függhet minden mástól.
    Mutasd a teljes hozzászólást!
  • nova76:
    az előbbi példámnak (több millió rekordos adatbázis elég sok látogatóval) jelenleg 8-15ms alatt van átlagban a lapgenerálási ideje. (Persze mögötte memcache-ben több giga adat van )

    erre lenne egy kerdesem: mennyi es milyen jellego adatot erdemes cachelni? olvastam arrol is hogy mysql tablat is lehet.. vagy konkretan errol van itt szo? mennyi a valoszinusege hogy ha egy adattablat cachelek, akkro az valami hiba folytan elveszik az eterben, es a modositasok eltunnek? ennek az elmeleterol akar priviben valaki tudna par percet szentelni ram ?:D
    Mutasd a teljes hozzászólást!
  • jol latom hogy az utolso tartalom meglehetosen regi ?:D
    Mutasd a teljes hozzászólást!
  • Ahogy Smacky is mondta, az oldal generálási sebességéről van szó. A symfony is pl. ezt méri alapból a saját developer toolbarjaval. (meg persze külön az sql-ek idejét és ilyeneket)

    Az, hogy amíg a firefox letölti az összes kapcsolódó tartalmat (képek, css, stb), és rendereli őket, az persze, hogy több - de a kérdés nem hiszem hogy erre vonatkozott, hanem arra, hogy a php lassú e.
    Mutasd a teljes hozzászólást!
  • Ülj be a szerverterem konzol szobájába, és IP cím alapján érd el a gépet.
    Ezzel csak azt akartam mondani, hogy amit te mérsz, az az, hogy a kérésre mennyi idő alatt érkezett meg a válasz a szervertől, amibe beleszámolódik a DNS lekérés, adat elküldés, adat átmegy routereket, switch-eken, stb.

    Kicsit off, de érdekes olvasmányok a gugli találatai a "latency vs bandwidth" kifejezésre.

    Mi eddig szerver oldali adat előállítási időről beszélgettünk, amit mondjuk ab-vel és hasonlókkal lehet benchmarkolni localhostról!!!

    Amit mi méregettünk, az kb ennyi:
    <?php $time = microtime(true); // itt a teljes oldal generálása $time = microtime(true) - $time; echo "Oldalgenerálás: " . ($time/1000) . "ms"; ?>
    Mutasd a teljes hozzászólást!
  • Én nem tudom hogy Ti mivel méritek.

    De nézzük firefox extended statusbarral, vagy a firebug net fülével.

    Nálam például egy oldal 2 fájlt szed le a szerverről. SQL egyikben sincs, néhány IF utsítás (user session létezik-e, kapott -e postolt user nevet és jelszót) után kirak egy login ablakot.
    Az egyik fájl egy css, ami a firefox firebug net füle szerint 17ms, a másik maga az oldal, ami 28ms. Aztán az egész (2request) 581ms alatt futott le. Ez a leggyorsabb oldal és még csak nem is symfony hanem sima pár soros php. Hogyan tudnám én ezt akár 100ms alá vinni?
    Szivesen venném az ötleteket.
    Mutasd a teljes hozzászólást!
  • Pl. üres php szinte nullla? :) pl. symfony alap kezdőlap? vagy egy általad létrehozott tetszőleges kvázi üres modul, ami lényegében csak html-t tesz ki, tehát productionben majd gyakorlatilag simán htmlként cachelve is lesz?
    Mutasd a teljes hozzászólást!
  • lacy:
    Az optimalizálás valahol az Appendix A részen van, te meg a Chapter 2-nél akadtál el. Szerintem ne ugord át a könyv nagy részét.
    Majd ha magabiztosan oldasz meg bonyolult (de akár lassú) feladatokat php-mysql -ben, akkor gondolkozz az optimalizáláson. Ha fejlődsz, előbb-utóbb sok optimalizálási trükk keresgélés és kérdezősködés nélkül, magadtól fog eszedbe jutni.
    Addig meg ne is akarj nagy terhelésű oldalt írni, mert nem csak a sebességgel, de főként a megbízhatósággal lesznek gondjaid.

    djcomplex:
    Smarty cache-t rányomva nem is fut le php kód, html lap kerül ki

    ez legfeljebb abban az esetben lehet közelítőleg igaz, ha a .tpl fileodban nincs semmilyen smarty tag. De akkor meg mi értelme a smarty-nak?
    Továbbá szerintem nem a smarty a meghatározó része egy weboldal optimalizálásának, sőt, én inkább úgy fogalmaznám meg, hogy ha már template rendszer, tudjon cachelni, de még az is egy lassító faktor azért, hogy a fejlesztés könnyebb legyen.

    Benjy:
    Ha ez egy home pc, akkor nagyából reálisak az eredmények. Ha normális szerver, akkor ha a teljes lapgenerálás 0.1 s fölött van, az már nem túl jó.
    Illetve a mért adatok akkor sem túl kedvezőek, ha ez egy terhelésmentes gépen történt egy konkurens felhasználóval.
    Saját tapazstalat: több millió rekordos adatbázist használó oldal fejlesztői oldala 0.x mp alatt töltődött kivétel nélkül, viszont 100-200 online látogató esetén már igencsak bele-bele csapott a másodperc fölötti lapgenerálási időbe.

    nova76:
    az előbbi példámnak (több millió rekordos adatbázis elég sok látogatóval) jelenleg 8-15ms alatt van átlagban a lapgenerálási ideje. (Persze mögötte memcache-ben több giga adat van )
    Mutasd a teljes hozzászólást!
  • 40ms? Nemhogy Symfonyval, de az életben nem láttam még ilyet. Mutass már egy ilyet!
    Mutasd a teljes hozzászólást!
  • Eressz ra egy JMetert annyi userrel, amennyire szamitasz egy virtualis gepben, melynek igenyek szerinte beallitod az eroforrasait, es tesztelheted, hogy milyen gyorsan mozog.
    Mutasd a teljes hozzászólást!
  • Attól függ mit csinál az oldal, de nekem általánosságban lassúnak tűnik - főleg ha szerveren is ilyen idő alatt szolgálsz ki. Mármint az idő, a memória egész jó.


    (Nekem symfony, pentium dualcore laptop, 3-as load, sokkal kevesebb az átlag. 0 sql queryvel ~40ms, átlagos sql mellett meg úgy ~300ms)

    (viszont alapvetően célszerűbb lenne valami relevánsabb mérést is csinálnod, pl. ab-vel)
    Mutasd a teljes hozzászólást!
  • Sziasztok

    Készítek egy weboldalt, a Joomla keretrendszert választottam (bár inkább szeretem magamtól megírni illetve jobban testreszabni az alapvető funkciókat, átlátni a rendszert, de sajnos az időhiány rákényszerített)

    Szerintetek mennyi a még elfogadható idő ami alatt a lap generálódjon, illetve nektek mi a tapasztalatotok, mennyi idő alatt készül el, mennyi memóriát használ?

    Használtam CakePHP keretrendszert is, ott is ekörül mennek debug módban az idők.

    Profil információ
    Application afterLoad: 0.002 seconds, 0.51 MB
    Application afterInitialise: 0.250 seconds, 4.40 MB
    Application afterRoute: 0.280 seconds, 4.75 MB
    Application afterDispatch: 0.515 seconds, 7.41 MB
    Application afterRender: 0.698 seconds, 8.85 MB
    Memóriahasználat
    9324512

    A gép nem valami gyors, ezen fejlesztek ezen van a szerver is.
    Intel 2,4 ghz, 1,5 gb memória.

    Annyi a kérdésem, hogy szerintetek ezek elfogadható idők-e?
    Mutasd a teljes hozzászólást!
  • A problémát felvetettem a Tudástárban!

    Tudástár
    Mutasd a teljes hozzászólást!
  • off - ja :)
    Mutasd a teljes hozzászólást!
  • off - te írod a web.buzz.hu-t?
    Mutasd a teljes hozzászólást!
  • Én pl. Smartyt használok és cacheelek, amit lehet.
    Beállítom, hogy a dinamikusan előállítot részek (adatbázisból vagy távoli forrásból származó adatok, pl. címoldali hírlista, rssből származó adatok, stb.) csak egyszer kérdezem le, mondjuk óránként.
    Smarty cache-t rányomva nem is fut le php kód, html lap kerül ki.
    Ez szerintem elég gyors tud lenni...
    Olyan hatalmas portált meg még nem csináltam, hogy nagyon bele kellene menni az sql gyorsításába, de szerintem Mo.-n sem sok van,ahol mondjuk egy 10-es skálán 6 fölé kellene menni sql optimalizálásban (itt persze nem egy helyes count() használatra gondolok). Most ennyi jutot eszembe.
    Mutasd a teljes hozzászólást!
  • Megoldas a sorszamlalasra, es meg a legoptimalisabbat is megtalalod itt

    Amugy en ugy erzem hogy nalad alap dolgokkal is vannak gondok, pl ez az includos dolog, szal lehet nem artana meg kicsit gyakorlatozni.

    Majd irok egy postot talan par trukkel amivel lehet gyorsitani ezt azt, de amugy google, meg tudastar...
    Mutasd a teljes hozzászólást!
  • Hali!

    Kezdi elveszteni a téma az eredeti értelmét (optimalizálás, gyorsítás) a konkrét kérdésekkel, amiknek a TUDÁSTÁRBAN A HELYÜK!
    Mutasd a teljes hozzászólást!
  • Nem értem pontosan mire gondolsz...
    A lekérdezésem ez:

    $f_sav_res = mysql_query( "SELECT * FROM f_topic ORDER BY t_date desc, t_time desc" ); while ( $egy_sor = mysql_fetch_array ( $f_sav_res ) ) { }
    Ez a forum2.php fájl amit a kezdőlapba(index.php) be include-oltam.

    Semmi probléma ezzel...működik! De csak abban az esetben, ha a forum2.php-ban is meghívom az MySQL-hez csatlakozó függvényt!

    Akkor jön a lenti hiba, ha csak az index.php-ben van a csatlakozó függvény meghívva.
    Mutasd a teljes hozzászólást!
  • Esetleg a forráskód, ami ezt előidézi? Amúgy mit adsz át a fetch_array-nak? A query erőforrás mutatóját kéne.
    Mutasd a teljes hozzászólást!
  • Nekem ez a megoldás nem müxik!

    Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in c:\appserv\www\my\portal\forum2.php on line 6

    Mi lehet a gond?
    Mutasd a teljes hozzászólást!
  • És mit használsz helyette?
    Az SQL COUNT utasítását?
    Mutasd a teljes hozzászólást!
  • Pontosan, hogy ne azt használjuk.

    Bár ez érdekes, mert egy agyonterhelt mysql szerver esetén jobb lehet.
    Mutasd a teljes hozzászólást!
  • Nem PHP-val számoljuk a rekordokat?
    Itt arra gondolsz, hogy ezt...
    $sorok_szama = mysql_num_rows( $lekerd );
    ...vagy pedig ne ezt használjuk?
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd