« 1 2 »
Autor Zpráva
Kajman_
Profil *
Vypadá to, že se dnes už přestala zobrazovat Yuhůova informační stránka o přetížení a místo toho se zobrazuje.
http://www.levny-hosting.cz/prekroceni-systemovych-zdroju + url domény v parametru.

To nám pokazí úspěšně roustoucí grafy

Nemůže za ty častější přetížení práce s user_topics aplikovaná od 1.12.2010? Možná bych to mohl o víkendu přepsat, aby to nebylo uložené jako text, ale jako více řádku jednoho uživatele do jiné tabulky typu innodb.

Možná by i pomohlo jen
update low_priority tabulka_uzivatelu ...

Taky jsem si říkal, jestli u dotazu s výpisem jednoho vlákna nezakázat sql_cache, ale tím si vůbec nejsem jistý, ale na týden by se to mohlo zkusit.
select sql_no_cache ... from tabulka_postu...

Nebo dá se nějak poznat, kde bývá ty poslední měsíce úzké hrdlo?
Chamurappi
Profil
Reaguji na Kajmana:
se dnes už přestala zobrazovat Yuhůova informační stránka
Myslím, že občas se stále zobrazuje, protože tu hostingovou hlášku jsem poprvé potkal už někdy včera dopoledne.
Ta hostingová hláška mi mimochodem připadá docela potupná. Návštěvníkům se ukazuje, že diskuse nestíhá a že běží jen na nějakém levném hostingu

Nebo dá se nějak poznat, kde bývá ty poslední měsíce úzké hrdlo?
Nevím. Pomohly by ti HTTP logy?
Pokud nemůžeme snadno povypínat jednotlivé části, co je zkusit naopak víc zatížit?

Možná by i pomohlo jen
Mám-li něco změnit v ostré verzi, prosím o trochu specifičtější pokyny.
Kajman_
Profil *
Mám-li něco změnit v ostré verzi, prosím o trochu specifičtější pokyny.
To sql_no_cache by se doplňovalo v setup_mysql.php u $n == 7, kdy by místo
SELECT poster_id,

bylo
SELECT sql_no_cache poster_id,

ale to si nejsem jistý, jestli nebude kontraproduktivní.

To low_priority bych zkusil přidat u nového dotazu. Ale stejně si myslím, že bude lepší ta čtená vlákna ukládat do samostatné tabulky. Tohle by se možná mohlo na ostré mohlo i zakomentovat třeba na týden, jestli to není nový kámen úrazu.

Místo low_priority by možná šlo změnit typ tabulek z myisam na innodb, ale to by určitě chtělo předtím všechno zazálohovat a asi i otestovat vliv na výkon. S mysql nemám moc zkušeností. Třeba ještě někdo něco poradí.

Pomohly by ti HTTP logy?
Asi ne. Kdysi (možná hosting) řekl Yuhůovi, že nejvíc výkonu žere databáze. Z logů se asi nic takového poznat nedá. Jedině pak na lepší emulaci zátěže, když by se dělaly nějaké lokální testy s innodb variantou tabulek.

Když roboti dělají 75% procent GET zátěže, možná by se dala zase zvážit přísnější varianta robots.txt, která povolí jen roboty, kteří jsou pro diskusi přínosní.
Chamurappi
Profil
Koukám, že se nám tu objevil profiler. Je z něj patrné, v čem může být problém?
Ve výchozím stavu je rozbalený, to je uživatelsky docela nepohodlné :-)
Edit z 16. 3.: Opravdu to bylo hodně nepohodlné, vyndal jsem si svoji IP ze seznamu, s DB stejně asi nic nenadělám.


Reaguji na Kajmana:
Tohle by se možná mohlo na ostré i zakomentovat třeba na týden
Staniž se. Ovšem nyní těžko posoudíme účinnost jakéhokoliv opatření, když nám hostingová hláška obchází statistiku.
Podívám se večer do administrace hostingu, jestli v ní nepřibyly nějaká data vyvozená z té hostingové hlášky.

To sql_no_cache by se doplňovalo v setup_mysql.php
Na to jsem zatím nesahal, uvidíme, zda ta jedna úprava něco změní.

Asi ne. Kdysi (možná hosting) řekl Yuhůovi, že nejvíc výkonu žere databáze.
Pak jsme několik let žili v dojmu, že to platí pořád a že se situace zhoršuje, a nakonec z logů Yuhů vyčetl, že nás bombarduje pár robotů, které jsme zakázali a bylo po přetížení. Takže teď asi nevíme nic konkrétního. Sám jsem ale v předvčerejším logu žádnou podezřelou aktivitu nenašel. Nejaktivnější IP adresu měl Googlebot.

Když by nestíhala databáze, neprojevovalo by se to spíš celkovou leností, viditelnými SQL chybami a timeouty? Nezdá se mi, že klientské požadavky svádějí se serverem lítý boj o přežití, vypadá to, že je rovnou vykopne vyhazovač. Bez čekání.
Kajman_
Profil *
Chamurappi:
Koukám, že se nám tu objevil profiler

Kde? Já vím jen o tom čase generování stránky v #time, ale to tam je už dávno. Profilery často zatěžují server ze všeho nejvíc.

Nejaktivnější IP adresu měl Googlebot.
Zrovna ten jde ve webmaster tools ručně poladit, aby nebyl tak aktivní. Teď tam tuším uvádí průměrně nějakých 15 000 požadavků denně. Teď bych to zkusil pár dní nechat jen se tím zakomentovaným ukládáním navštívených vláken.
Str4wberry
Profil
Profiler se zobrazuje od včerejška jen v sandboxu vašim IP adresám. Pokud je tu Kajman z jiné IP, než ze které zakládal toto téma, tak ho nevidí.
Kajman_
Profil *
Str4wberry:
Nastav tam prosím raději ip z [#5]. Díky
Kajman_
Profil *
Chamurappi:
Podívám se večer do administrace hostingu, jestli v ní nepřibyly nějaká data vyvozená z té hostingové hlášky.

Našel jsi tam něco? Případně, nejsou kódy přetížení (možná 503) v přístupových lozích?
Chamurappi
Profil
Reaguji na Kajmana:
Žádné počítadlo zobrazení stránky o přetížení tam není.
Jsou tam nějaké grafy využití prostoru na disku, procesoru a databáze, ale nic rozumného jsem z nich nevyčetl. Zítra je sem hodím. Zaujalo mě na nich jen to, že využíváme tři a půl GB z dostupného gigabajtu prostoru a že v prosinci začal výrazněji růst objem přenesených dat, až se dostal na současný historický rekord.

nejsou kódy přetížení (možná 503) v přístupových lozích?
Nejsou.
Chamurappi
Profil
Přináším slíbené obrázky zátěže serveru a databáze.

# Zátěž serveru



































# Zátěž databáze



































# Přenesená data za posledních čtyři a půl roku







Zabrané místo

Asi nezajímavé. Jsou to nepřetržitě rostoucí 3 GB, zaplněné převážně zapakovanými a zvenku nepřístupnými HTTP logy od července 2007 do teď.

AWStats

Moderátoři najdou v moderátorském doupěti odkaz na statistiky z logů.
Doporučuji k nahlédnutí i moderátorům, kteří se o přetížení nezajímají. Prosinec 2010 je nějaký rozbitý, ale jinak jsou tam kompletní data od konce května 2010 do teď. Počty přístupů, odkazující stránky, hledaná slovní spojení…
Davex
Profil
Vyskočilo mi přetížení během prohlížení statistik, kde není žádná databáze ani PHP, takže z toho odvozuji, že přetížení nezpůsobuje databáze, ale možná velký počet HTTP dotazů najednou.

Zatím mě napadlo jen zapnout kešování favicony, která má teď nastaveno defaultní max-age=0. Možná by se tak trochu ušetřilo.

ExpiresByType image/x-icon A30000000
Kajman_
Profil *
Pokud je trochu rezerva u vytížení cpu, ale jsou atakovány hraniční limity pro přenos dat, určite stojí za test zapnout mod deflate i pro text/html. Nyní sice není ani pro css a js, ale Yuhů byl tenkrát pro zapnutí.

    * Compressing http://diskuse.jakpsatweb.cz/templates/djpw.js could save 87.4KiB (70% reduction).
    * Compressing http://diskuse.jakpsatweb.cz/templates/djpw_jush.js could save 67.9KiB (64% reduction).
    * Compressing http://diskuse.jakpsatweb.cz/ could save 23.6KiB (81% reduction).
    * Compressing http://diskuse.jakpsatweb.cz/templates/djpw.css could save 12.7KiB (71% reduction).
    * Compressing http://diskuse.jakpsatweb.cz/templates/djpw_jush.css could save 2.0KiB (75% reduction).
    * Compressing http://diskuse.jakpsatweb.cz/statistika.js could save 624B (55% reduction).
    * Compressing http://diskuse.jakpsatweb.cz/reklamy/reklama.js could save 470B (44% reduction).

Jinak z těch mysql grafů to vypadá, že ty updaty posledních navštívení vláken mohly docela databázi zahulit. Asi hlavně proto, že se prováděly i pro nepřihlášené uživatele. Myisam tabulky, co jsou teď používány, jsou vhodnější tam, kde se hodně čte a málo zapisuje. Ale pro tuhle věc už můžou zamykáním celé tabulky brzdit.

Z grafů přístupů je nejspíš pěkně vidět benevolentnější robots.txt od září 2009.

Ale ty grafy se těžko porovnávají, když mají každý den jiný rozsah.

Co prozatím google botovi ponížit přes webmaster tools prodlevy před jednotlivými požadavky? (V awstats není v robotech seznambot, ale podle přístupů dle ip, má seznambot společně s jeho beta variantou nad googlebotem, navrch. Třeba by Yuhů mohl nastavit, aby generovaly zátěž spíše v nočních hodinách;)
Chamurappi
Profil
Teď jsem doplnil denní grafy přenosů, kde jsou i počty požadavků a vytížení CPU. (Dříve jsem si jich v administraci nevšiml.)


Reaguji na Davexe:
zapnout kešování favicony, která má teď nastaveno defaultní max-age=0
Dobrý postřeh. Obzvláště, když tu těch ikon máme přes 30. Kešování zapnuto.

Počet HTTP dotazů bychom také mohli snížit snížením počtu obrázků, jak kdysi navrhoval tiso.


Reaguji na Kajmana:
určite stojí za test zapnout mod deflate i pro text/html
Zkusil jsem ho nyní zapnout pro HTML, CSS i JS.

Z grafů přístupů je nejspíš pěkně vidět benevolentnější robots.txt od září 2009.
Vskutku. Ale nelituji toho, roboti jsou kamarádi, i když nás občas přizabíjí :-)

ty grafy se těžko porovnávají, když mají každý den jiný rozsah
Nic lepšího z toho nevymáčknu. Zkoušel jsem, jestli ten graf-generující skript nevezme jako parametr i měsíc, když umí roky a dny. Marně. Kupodivu ale umí vygenerovat věrohodně vypadající graf pro budoucí den, netuším, odkud bere data :-)

Co prozatím google botovi ponížit přes webmaster tools prodlevy před jednotlivými požadavky?
Nejprve bych počkal, jaké dopady budou mít dnešní změny.
Joker
Profil
Davex:
Vyskočilo mi přetížení během prohlížení statistik, kde není žádná databáze ani PHP, takže z toho odvozuji, že přetížení nezpůsobuje databáze, ale možná velký počet HTTP dotazů najednou.
Není to tak, že po přetížení hosting přestane zobrazovat veškeré stránky? Čili příčinou přetížení nemusela být přímo ta stránka.
Alespoň to jsem si odvodil z hlášky na té stránce (že počítadlo se resetuje každých 10 minut či co)
Davex
Profil
Chamurappi:
> „určite stojí za test zapnout mod deflate i pro text/html“
> Zkusil jsem ho nyní zapnout pro HTML, CSS i JS.
JS bych raději nekomprimoval pro Explorer 6 - v kombinaci se Set-Cookie to někdy dělá neplechu.

Joker:
Ta chybová hláška je matoucí, protože o pár vteřin později se původní stránka zobrazí normálně.
Kajman_
Profil *
Chamurappi:
Obzvláště, když tu těch ikon máme přes 30
Ale to jsou image/gif, ty to měly nastavené.

Kupodivu ale umí vygenerovat věrohodně vypadající graf pro budoucí den
Nemají tam převod na absolutní hodnotu, kdy zítra=včera? Nebo mají super analýzu, která to odhadne :-)

Dnes se mi žádná stránka s přetížením nepřihodila, tak třeba jen ten deflate pomůže dostat se pod limity hostingu. Možná by se mohlo balit i xml (použité u rss).
Chamurappi
Profil
Přenesená data jsme gzipováním srazili docela vydatně — doplněn graf z 16. března.


Reaguji na Davexe:
JS bych raději nekomprimoval pro Explorer 6
Upraveno. V odkázaném vlákně to dělalo neplechu spíš u samotné HTML stránky, ale už jsem viděl i neplechu u JS.


Reaguji na Kajmana:
Ale to jsou image/gif
Ikony jsou opravdu ikony.

Nemají tam převod na absolutní hodnotu, kdy zítra=včera?
Je to modulo devadesáti. Zítřejší graf vypadá stejně jako 89 dní starý.

Dnes se mi žádná stránka s přetížením nepřihodila
Mně se bohužel jednou ukázala.
Chamurappi
Profil
Doplněn graf z dalšího dne.


Reaguji na Kajmana:
má seznambot společně s jeho beta variantou nad googlebotem, navrch. Třeba by Yuhů mohl nastavit, aby generovaly zátěž spíše v nočních hodinách
Seznambot je ta pravidelná špička okolo páté hodiny ráno. (Pak sem ještě chodí celý den průběžně seznamácký foťák.)
Davex
Profil
Nemůže se někdo zeptat technické podpory hostingu, který limit diskuse překračuje? Pokud Yuhů platí za hosting tolik, tak bych tam neočekával omezení, která by měla diskusi takto omezovat.
Chamurappi
Profil
K té včerejší špičce v 18 hodin se mi už přiznal Kajman, takže ta nám už nemusí vrtat hlavou.


Reaguji na Davexe:
Už jsem hostingu psal ve středu skrz formulář, který se používal, dokud ještě nebyl levný. Napoprvé mi to vynadalo, že jsem nevyplnil telefon, po nápravě mi to stejně červeně psalo, že formulář můžu znovu poslat až za 10 minut, což mohlo, ale nemuselo znamenat, že se neodeslal. Počkal jsem hodinu, zkusil to znovu a napsalo mi to znovu, takže fakt nevím, jestli to funguje a z nějakého důvodu na mě dlabou, nebo jestli to nefunguje kvůli nějaké mé chybě, nebo jestli to už dávno celkově přestalo fungovat (žádný statický soubor tam nemá novější Last-Modified než konec dubna 2010). Tak či onak je to chytře vymyšlený formulář brzdící veškeré neurgentní dotazy :-)

Teď jsem jim zkusil napsat na jedinou e-mailovou adresu, kterou uvádějí na svém levném oranžovém webu (k tomu ten přívlastek „levný“ pasuje docela dobře). Pokud ten e-mail dorazí, možná se něco dozvíme.
Kajman_
Profil *
Chamurappi:
Jestli budeš cvakat další screenshoty, nechceš je dát k těm minulým, ať se při porovnání nemusí tolik jezdit po stránce? Jinak v pátek jsem možná zase nějakou tu špičku způsobil. Chvíli trvalo, než jsem našel nástroj a způsob, jak těch 800 tisíc blábolů zazálohovat na testy i přes překážky, které tam v podobě nějakých timelimitů nebo čehosi hosting připravil.
Chamurappi
Profil
Dostal jsem odpověď:
dobry den,
omlouvame se, ten problem s 503/presmerovanim by mel byt vyresen a zase funkcni u vasi domeny.
jde o pretizeni na zaklade spotrebovaneho cpu.
takze vubec nereste nic s databazi/pocty dotazu, spise php.

Tak. Co teď?
Jestli tomu dobře rozumím, tak přítomnost profileru a zapnuté gzipování procesoru příliš neodlehčují.


Reaguji na Kajmana:
nechceš je dát k těm minulým
Dal jsem všechny k sobě a doplnil jsem i aktuální databázové.
Jan Tvrdík
Profil
Chamurappi:
Co teď?
Pustit profiler (zdarma / komerční [má trial]) na PHP nebo opět zvážit přechod jinam (asi VPS).
Kajman_
Profil *
Chamurappi:
Jestli tomu dobře rozumím, tak přítomnost profileru a zapnuté gzipování procesoru příliš neodlehčují.

Profiler je teď asi jen v sandboxu a pro tři ip. Ale to je asi nějaký zjednodušený, co hlídá spíš jen dotazy a ne jednotlivé kusy php. Nějaký ten doporučený profiler se může nainstalovat jen u někoho doma a to už by mohlo stačit k nalezení případných problémových míst. (S takovýmto laděním php nemám žádné zkušenosti, s tím asi moc nepomohu, ale třeba tam taky něco málo vykoukám.)

Zapnutí gzipu na cpu má asi nepatrný vliv, když třeba porovnám serverové logy z 4.3. a 19.3, kdy je odpoledne kolem 10 000 přístupů za hodinu, tak cpu nevypadá o moho víc zatížené.
Kajman_
Profil *
Vypadá to, že kdyby se podařilo přepsat funkci parseTpl lépe, mohlo by to pár procet ušetřit.
Chamurappi
Profil
Reaguji na Kajmana:
function parseTpl($tpl) {
    $qs = array();
    $qv = array();
    $ex = explode('{$', $tpl);
    $exsize=sizeof($ex); //kaj 22.3.2011 at se nemusi pocitat pokazde
    for ($i = 0; $i <= $exsize; $i++) {
        if (!empty($ex[$i]) and strpos($ex[$i], '}') !== false) {
            $xx = explode('}', $ex[$i]);
            if (strpos($xx[0], '[') !== false) {
                $clr = explode('[', $xx[0]);
                $sp = $clr[1] + 0;
                $clr = $clr[0];
                if (!in_array($clr, $qs)) {
                    $qs[] = $clr;
                    global ${$clr}
                    ;
                }
                $to = ${$clr}
                        [$sp];
            } else {
                if (!in_array($xx[0], $qv)) {
                    $qv[] = $xx[0];
                    global ${$xx[0]}
                    ;
                }
                $to = ${$xx[0]}
                ;
            }
            $tpl = str_replace('{$' . $xx[0] . '}', $to, $tpl);
        }
    }
    return $tpl;
}
Tuhle příšeru?


Chce si to někdo zkusit?
joe
Profil
Ta funkce
parseTpl(...)
se volá při každém načtení stránky? Nebylo by lepší nechat z toho nechat vygenerovat nějaký soubor, který se použije při dalším načtení? Případně to udělat bez šablon :-)
Kajman_
Profil *
Chamurappi:
Chce si to někdo zkusit?

Možná můžeme použít něco jako

function parseTpl($tpl) {
	extract($GLOBALS,EXTR_SKIP);
	return eval("return <<<EOT\n$tpl\nEOT;\n");
}

Vypadá to rychlejší, jen by se musely zkontrolovat všechny šablony, zda to s nimi takhle půjde. V téhle funkci je pak nejnáročnější extract, který si můžeme odpustit, pokud do všech šablon přepíšeme zápis
{$posterName}
na
{$GLOBALS['posterName']}

doplněno: přidáš prosím časem zase čerstvé grafy? Teď už se dají porovnávat s grafy stránky o přetížení.
Kajman_
Profil *
joe:
se volá při každém načtení stránky?
Počet volání bývá v desítkách.
Jan Tvrdík
Profil
Ono ideální by bylo úplně vyměnit ten stávající šablonovací systém (jestli se tomu tak dá vůbec říkat) za nějaký, který se kompiluje přímo do PHP a umí pracovat s parametry, podmínky a cykly. Problém těchto kompilačních systémů je v tom, že je třeba zajistit atomicitu a automatickou invalidaci cache.
« 1 2 »

Vaše odpověď


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: