Jak zlepšit odezvu webového projektu s větší databází a návštěvností

Napsal johnyzpodoli;791487

Web jede na solidním serveru, nejpomalejší SQL dotazy jsou většinou několikanásobné joiny s agregací apod

Často je rychlejší udělat několik jednodušších SQL dotazů než jeden složitý který bude obsahovat "všechno".

Takže výsledek tohoto threadu je, že po doplnění 4 indexů do databáze se web rozjel až neskutečně. statistika pro /tabor/průměrná doba pro generování stránky- 3,8 sekundy bez keše a indexů,- 0,08 sekundy s kešíbez indexů- 0,18 sekundy s INDEXYje vidět, že data z SQL serveru jdou pořád trošku pomaleji než z keše, na druhou stranu kompletní vygenerování stránky za 0,2 sekundy už mi připadá velice dobré a není třeba se tím tedy dál trápit. Zdá se, že výrazně omezím kešování, nechám ho asi pouze tam, kde se ta data opravdu "nemění".děkuji za podnětné nápady, aktuálně studuji knihu kde se vše dočítám

No vida, blahopřeju, že jste se do toho pustil. Kešování zkuste nastavit přímo na úrovni databáze. Znám jen MySQL, tam lze cachovat v paměti celé tabulky, indexy i přímo výsledky dotazů.

Super, tož to aspoň k něčemu bylo :)Jinak 2 oham:ad 4) Zbytečná snaha udělat vše jedním dotazem - je rychlejší 200 dotazů co zaberou 0.002s než jeden co zabere 5s.- toto je velmi diskutabilní, aby dotaz trval 5s, to už by musel být opravdu hodně špatně napsaný a databáze až nechutně velká - Uvedu konkrétní příklad s joiny přes 11 tabulek, použitím case (6x), několik matematických oprací, jedná se o sesumírování výpisu produktů, přičemž se sbírají kromě základních dat také data z jiných tabulek (dostupnosti, výrobci, skupiny marže, cenová pásma, užv skupiny, pevné/akční ceny) a v jednom dotazu se přímo vypočítávají pomocí různých kriterií pro produkty jednou ze 6 metod (v podmínkách je volba, která se použije), zkusmo jsem si teď v adminu vypsal do prohlížeče 10000 produktů, dotaz samotný trval 1.2s na VPS 1:8 u WEDOS (60 GB HDD, 2 GB RAM, 2 proc./Fedora 15 ), zbytek skriptu nulanula nic. Ten VPS uvádím jako objektivnější kriterium než lokální konfig u sebe na laptopu. Kdybych sesbírání detailních dat řešil namísto joiny v následném cyklu, jednal bych se obral o možnost filtrovat dle kriterií už před výběrem dat a jednak by to bylo výrazně pomalejší, neboť kdyby jednotlivý dotaz zabral 0.0001 sekundy a další zlomky sekund by připadly na cyklus jako takový, tak se dostaneme k mnohem vyššímu číslu než je jeden a půl sekundy. Teď to fakt nemyslím konfrontačně, jen jsem zkoušel opravdu několik přístupů, když jsem systém ladil a velmi složité dotazy mi přišly vždy rychlejší. Je to takto testováno až do 500000 produktů, přičemž jako produktová data byly použity zmnožené produkty z HPtronic importu. U článků bude situace jednodušší o to, že není třeba vyhodnocovat ceny a lze se proto vyhnout matematickým operacím a dost pravděpodobně i CASE a IF. Nechci tvrdit, že to tak bude vždy, ale moje zkušenost je prostě taková a domnívám se, že větší počet jednoduchých dotazů na DB obecně není lepším řešením. Tedy možná je, ale snad pouze v případech, kdy web běží na opravdu slabém hostingu s velmi omezenými zdroji, kdy je nutno k tomuto přistoupit prostě proto, aby se nesesypal server kvůli přečerpání paměti.

Toto mi přišlo na první pohled jako zajímavá brožurka k tématu, zařadil jsem jí asi na 387. pozici knížek, který bych rád alespoň prolistoval :) http://use-the-index-luke.com/