Ahojte, rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout. Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte? Díky! Stanislav Kocanda -- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o. telefon: +420 776 643 433 e-mail: stanislav.kocanda@vanio.cz skype: kocandas
Hoy, zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu. Jarda ------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 e-mail: stanislav.kocanda@vanio.cz skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z pohledu I/O operaci zalezi na tom, ktere to jsou. Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene. Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je staci presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace, tak se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb, coz bys mel). Pokud mas hodne cteni, tak potrebujes vic pameti a trochu prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak, aby se vsechna data vesla do pameti, pak mysql pri cteni nebude sahat vubec na disk (akorat po startu, aby si vse nacachovala). Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je jich rozumne mnozstvi. Jarda ------ Original Message ------ From: "Jaroslav Skřivan" <skrivy@skrivy.net> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz>; "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:47:28 PM Subject: Re: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Hoy,
zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu.
Jarda
------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 e-mail: stanislav.kocanda@vanio.cz skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, díky za odpovědi oběma. Ačkoliv už jsme na aplikaci samotné udělali hodně performance-related úprav a cachujeme jako diví, ještě stále na ní je co zlepšovat a některé dotazy které aplikace vyprodukuje jsou hodně nepěkné. Během srpna máme v plánu stav zlepšit, tak uvidíme. Motivován odpověďmi jsme se pustil do zlepšování konfigurace MySQL a i když už jsem minimálně jednou tento fine-tuning dělal, překvapilo mě, kolik toho bylo špatně (hlavně innodb_buffer_pool_size). Takže po stránce optimalizací snad budeme připravení lépe než loni. :) Nicméně by mě přesto zajímalo, jaké jsou zhruba limity našich VPS? Chápu, že to je hodně individuální věc, ale alespoň řádově, s průměrnou webovou aplikací v PHP/MySQL a s rozumně nastaveným serverem, na jakou zátěž byste si troufali? Díky. Standa Dne 5.8.2014 20:00, Jaroslav Skřivan napsal:
Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z pohledu I/O operaci zalezi na tom, ktere to jsou.
Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene. Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je staci presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace, tak se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb, coz bys mel).
Pokud mas hodne cteni, tak potrebujes vic pameti a trochu prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak, aby se vsechna data vesla do pameti, pak mysql pri cteni nebude sahat vubec na disk (akorat po startu, aby si vse nacachovala).
Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je jich rozumne mnozstvi.
Jarda
------ Original Message ------ From: "Jaroslav Skřivan" <skrivy@skrivy.net> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz>; "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:47:28 PM Subject: Re: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Hoy,
zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu.
Jarda
------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 e-mail: stanislav.kocanda@vanio.cz skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, navrhujem ten server zatazit vopred a otestovat konfiguraciu :) Napr pomocou http://loadimpact.com/ alebo https://en.wikipedia.org/wiki/ApacheBench Ondrej 2014-08-05 23:42 GMT+02:00 Stanislav Kocanda <stanislav.kocanda@vanio.cz>:
Ahoj,
díky za odpovědi oběma. Ačkoliv už jsme na aplikaci samotné udělali hodně performance-related úprav a cachujeme jako diví, ještě stále na ní je co zlepšovat a některé dotazy které aplikace vyprodukuje jsou hodně nepěkné. Během srpna máme v plánu stav zlepšit, tak uvidíme. Motivován odpověďmi jsme se pustil do zlepšování konfigurace MySQL a i když už jsem minimálně jednou tento fine-tuning dělal, překvapilo mě, kolik toho bylo špatně (hlavně innodb_buffer_pool_size). Takže po stránce optimalizací snad budeme připravení lépe než loni. :)
Nicméně by mě přesto zajímalo, jaké jsou zhruba limity našich VPS? Chápu, že to je hodně individuální věc, ale alespoň řádově, s průměrnou webovou aplikací v PHP/MySQL a s rozumně nastaveným serverem, na jakou zátěž byste si troufali?
Díky.
Standa
Dne 5.8.2014 20:00, Jaroslav Skřivan napsal:
Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z pohledu
I/O operaci zalezi na tom, ktere to jsou.
Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene. Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je staci presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace, tak se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb, coz bys mel).
Pokud mas hodne cteni, tak potrebujes vic pameti a trochu prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak, aby se vsechna data vesla do pameti, pak mysql pri cteni nebude sahat vubec na disk (akorat po startu, aby si vse nacachovala).
Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je jich rozumne mnozstvi.
Jarda
------ Original Message ------ From: "Jaroslav Skřivan" <skrivy@skrivy.net> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz>; "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:47:28 PM Subject: Re: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Hoy,
zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu.
Jarda
------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 e-mail: stanislav.kocanda@vanio.cz skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, Apachebench používám pravidelně, ale má to své limity, protože tím jak to dotazuje stále stejnou stránku, tak to většinou zcela pokryje Varnish a výsledky jsou mnohem lepší, než pak realita (potřeboval bych dotazovat náhodně více různých stránek a hlavně bych potřeboval dotazy se sessions, protože velká část provozu pochází od přihlášených uživatelů, které Varnish pochopitelně necachuje). Na ten Load Impact se mrknu, díky za tip. Standa Dne 5.8.2014 23:45, Ondrej Galbavý napsal:
Ahoj,
navrhujem ten server zatazit vopred a otestovat konfiguraciu :) Napr pomocou http://loadimpact.com/ [17] alebo https://en.wikipedia.org/wiki/ApacheBench [18]
Ondrej
2014-08-05 23:42 GMT+02:00 Stanislav Kocanda <stanislav.kocanda@vanio.cz [19]>:
Ahoj,
díky za odpovědi oběma. Ačkoliv už jsme na aplikaci samotné udělali hodně performance-related úprav a cachujeme jako diví, ještě stále na ní je co zlepšovat a některé dotazy které aplikace vyprodukuje jsou hodně nepěkné. Během srpna máme v plánu stav zlepšit, tak uvidíme. Motivován odpověďmi jsme se pustil do zlepšování konfigurace MySQL a i když už jsem minimálně jednou tento fine-tuning dělal, překvapilo mě, kolik toho bylo špatně (hlavně innodb_buffer_pool_size). Takže po stránce optimalizací snad budeme připravení lépe než loni. :)
Nicméně by mě přesto zajímalo, jaké jsou zhruba limity našich VPS? Chápu, že to je hodně individuální věc, ale alespoň řádově, s průměrnou webovou aplikací v PHP/MySQL a s rozumně nastaveným serverem, na jakou zátěž byste si troufali?
Díky.
Standa
Dne 5.8.2014 20:00, Jaroslav Skřivan napsal:
Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z pohledu I/O operaci zalezi na tom, ktere to jsou.
Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene. Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je staci presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace, tak se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb, coz bys mel).
Pokud mas hodne cteni, tak potrebujes vic pameti a trochu prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak, aby se vsechna data vesla do pameti, pak mysql pri cteni nebude sahat vubec na disk (akorat po startu, aby si vse nacachovala).
Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je jich rozumne mnozstvi.
Jarda
------ Original Message ------ From: "Jaroslav Skřivan" <skrivy@skrivy.net [10]> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [11]>; "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [12]> Sent: 8/5/2014 7:47:28 PM Subject: Re: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Hoy,
zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu.
Jarda
------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz [6]> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [7]> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net [1]). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 [2] e-mail: stanislav.kocanda@vanio.cz [3] skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [4] http://lists.vpsfree.cz/listinfo/community-list [5]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [8] http://lists.vpsfree.cz/listinfo/community-list [9]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [13] http://lists.vpsfree.cz/listinfo/community-list [14]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [15] http://lists.vpsfree.cz/listinfo/community-list [16]
Links: ------ [1] http://www.burzaucebnic.net [2] http://mail.vanio.cz/tel:%2B420%20776%20643%20433 [3] mailto:stanislav.kocanda@vanio.cz [4] mailto:Community-list@lists.vpsfree.cz [5] http://lists.vpsfree.cz/listinfo/community-list [6] mailto:stanislav.kocanda@vanio.cz [7] mailto:community-list@lists.vpsfree.cz [8] mailto:Community-list@lists.vpsfree.cz [9] http://lists.vpsfree.cz/listinfo/community-list [10] mailto:skrivy@skrivy.net [11] mailto:community-list@lists.vpsfree.cz [12] mailto:community-list@lists.vpsfree.cz [13] mailto:Community-list@lists.vpsfree.cz [14] http://lists.vpsfree.cz/listinfo/community-list [15] mailto:Community-list@lists.vpsfree.cz [16] http://lists.vpsfree.cz/listinfo/community-list [17] http://loadimpact.com/ [18] https://en.wikipedia.org/wiki/ApacheBench [19] mailto:stanislav.kocanda@vanio.cz
1) pridat session a "znahodnit" pozadavky neni problem, napr.: my $c=1; while ($c < 5000) { my $a = `ab -n 1 -c 1 -H "Accept: text/xml" -C my_session=5a4ed0c68b9595cb1aed93cbd6b1917f6a2b3aef http://xxx.xxx.com/rest/location/event/$c`; $c++; } 2) zapni si logovani vsech dotazu do db. pomalost databaze muze byt zpusobena a) velkym mnozstvim jednoduchych dotazu - videl jsem i katastroficke scenare kdy radek tabulky na vystupu vygeneroval jeden ci vice dotazu do DB - b) malym mnozstvim slozitych dotazu - zde je potreba zkontrolovat dotazy, indexy atd... kazdy dotaz vzit, provest EXPLAIN ANALYZE pokud neco takoveho mysql Dne 5. srpna 2014 23:53 Stanislav Kocanda <stanislav.kocanda@vanio.cz> napsal(a):
Ahoj,
Apachebench používám pravidelně, ale má to své limity, protože tím jak to dotazuje stále stejnou stránku, tak to většinou zcela pokryje Varnish a výsledky jsou mnohem lepší, než pak realita (potřeboval bych dotazovat náhodně více různých stránek a hlavně bych potřeboval dotazy se sessions, protože velká část provozu pochází od přihlášených uživatelů, které Varnish pochopitelně necachuje).
Na ten Load Impact se mrknu, díky za tip.
Standa
Dne 5.8.2014 23:45, Ondrej Galbavý napsal:
Ahoj,
navrhujem ten server zatazit vopred a otestovat konfiguraciu :) Napr pomocou http://loadimpact.com/ [17] alebo https://en.wikipedia.org/wiki/ApacheBench [18]
Ondrej
2014-08-05 23:42 GMT+02:00 Stanislav Kocanda <stanislav.kocanda@vanio.cz [19]>:
Ahoj,
díky za odpovědi oběma. Ačkoliv už jsme na aplikaci samotné udělali hodně performance-related úprav a cachujeme jako diví, ještě stále na ní je co zlepšovat a některé dotazy které aplikace vyprodukuje jsou hodně nepěkné. Během srpna máme v plánu stav zlepšit, tak uvidíme. Motivován odpověďmi jsme se pustil do zlepšování konfigurace MySQL a i když už jsem minimálně jednou tento fine-tuning dělal, překvapilo mě, kolik toho bylo špatně (hlavně innodb_buffer_pool_size). Takže po stránce optimalizací snad budeme připravení lépe než loni. :)
Nicméně by mě přesto zajímalo, jaké jsou zhruba limity našich VPS? Chápu, že to je hodně individuální věc, ale alespoň řádově, s průměrnou webovou aplikací v PHP/MySQL a s rozumně nastaveným serverem, na jakou zátěž byste si troufali?
Díky.
Standa
Dne 5.8.2014 20:00, Jaroslav Skřivan napsal:
Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z
pohledu I/O operaci zalezi na tom, ktere to jsou.
Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene. Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je staci presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace, tak se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb, coz bys mel).
Pokud mas hodne cteni, tak potrebujes vic pameti a trochu prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak, aby se vsechna data vesla do pameti, pak mysql pri cteni nebude sahat vubec na disk (akorat po startu, aby si vse nacachovala).
Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je jich rozumne mnozstvi.
Jarda
------ Original Message ------ From: "Jaroslav Skřivan" <skrivy@skrivy.net [10]> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [11]>; "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [12]> Sent: 8/5/2014 7:47:28 PM Subject: Re: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Hoy,
zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu.
Jarda
------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz [6]> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [7]> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net [1]). Loni v září jsme s tím měli
celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 [2] e-mail: stanislav.kocanda@vanio.cz [3]
skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [4] http://lists.vpsfree.cz/listinfo/community-list [5]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [8] http://lists.vpsfree.cz/listinfo/community-list [9]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [13] http://lists.vpsfree.cz/listinfo/community-list [14]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [15] http://lists.vpsfree.cz/listinfo/community-list [16]
Links: ------ [1] http://www.burzaucebnic.net [2] http://mail.vanio.cz/tel:%2B420%20776%20643%20433 [3] mailto:stanislav.kocanda@vanio.cz [4] mailto:Community-list@lists.vpsfree.cz [5] http://lists.vpsfree.cz/listinfo/community-list [6] mailto:stanislav.kocanda@vanio.cz [7] mailto:community-list@lists.vpsfree.cz [8] mailto:Community-list@lists.vpsfree.cz [9] http://lists.vpsfree.cz/listinfo/community-list [10] mailto:skrivy@skrivy.net [11] mailto:community-list@lists.vpsfree.cz [12] mailto:community-list@lists.vpsfree.cz [13] mailto:Community-list@lists.vpsfree.cz [14] http://lists.vpsfree.cz/listinfo/community-list [15] mailto:Community-list@lists.vpsfree.cz [16] http://lists.vpsfree.cz/listinfo/community-list [17] http://loadimpact.com/ [18] https://en.wikipedia.org/wiki/ApacheBench [19] mailto:stanislav.kocanda@vanio.cz
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
S nejvetsi pravdepodobnosti spatne nastavena MySQL. Ta databaze ma slusnej pocet nastaveni, ktery maji vliv na alokaci pameti, coz je alfou a omegou mezi tim, ze to odmaka system jako celek, nebo si podrzi pracovni data v pameti. Nemusi byt nutne spatne navrzene schema, staci spatne pametove nastavit MySQL server a uz to krouha disky, jelikoz my mame na masinach efektivnejsi cache, nez bezne vidite v linuxu na ostatnich fs (mluvim o ZFS ARC), tak ta databaze vyzere o hodne vic CPU casu, nez by musela a az potom, kdyz ani ARC se zprefetchem nijak nevystihuji ten jeji workload, se saha realne na rotacni disky. Vetsine takovych bordelujicich VPS krouham CPU dolu, aby si lidi tu DB lip nastavili. Ten manual MySQL neni slozity, navic spousta z tech nastaveni se da vcelku snadno experimentalne overit na edge cases (staci se podivat na nejcastejsi queries + slow query log). Samotna MySQL query cache je tak rychla, ze nema smysl pouzivat Memcache pro naprostou vetsinu use-cases, kde jsem ho videl do ted, to ma smysl na opravdu velke deploymenty, kde je zatez na cache uz dela takovou zatez na CPU, ze je lepsi cache distribuovat (po siti!). Je jednodussi naucit se nastavit MySQL. Jedina potencialne pruserova situace nastava, kdyz se casto dela query, ktera bezi dlouho, ale je ulozitelna v query cache a v aplikaci se takova query casto vola. Nejhorsi je takovymu systemu menit casto data pod zadkem, to je potom spatny navrh schema te db, pravdepodobne programatora, ktery neco takoveho napise, nespasi zadny externi caching, protoze si neumi hlidat atomicnost dat, jak je potreba (experti na to maji asi lepsi vyrazy). snajpa Sent from your iPad
On 06 Aug 2014, at 09:21, Tomáš Valoušek <valy23@gmail.com> wrote:
1) pridat session a "znahodnit" pozadavky neni problem, napr.:
my $c=1;b while ($c < 5000) { my $a = `ab -n 1 -c 1 -H "Accept: text/xml" -C my_session=5a4ed0c68b9595cb1aed93cbd6b1917f6a2b3aef http://xxx.xxx.com/rest/location/event/$c`; $c++; }
2) zapni si logovani vsech dotazu do db. pomalost databaze muze byt zpusobena a) velkym mnozstvim jednoduchych dotazu - videl jsem i katastroficke scenare kdy radek tabulky na vystupu vygeneroval jeden ci vice dotazu do DB - b) malym mnozstvim slozitych dotazu - zde je potreba zkontrolovat dotazy, indexy atd... kazdy dotaz vzit, provest EXPLAIN ANALYZE pokud neco takoveho mysql
Dne 5. srpna 2014 23:53 Stanislav Kocanda <stanislav.kocanda@vanio.cz> napsal(a):
Ahoj,
Apachebench používám pravidelně, ale má to své limity, protože tím jak to dotazuje stále stejnou stránku, tak to většinou zcela pokryje Varnish a výsledky jsou mnohem lepší, než pak realita (potřeboval bych dotazovat náhodně více různých stránek a hlavně bych potřeboval dotazy se sessions, protože velká část provozu pochází od přihlášených uživatelů, které Varnish pochopitelně necachuje).
Na ten Load Impact se mrknu, díky za tip.
Standa
Dne 5.8.2014 23:45, Ondrej Galbavý napsal:
Ahoj,
navrhujem ten server zatazit vopred a otestovat konfiguraciu :) Napr pomocou http://loadimpact.com/ [17] alebo https://en.wikipedia.org/wiki/ApacheBench [18]
Ondrej
2014-08-05 23:42 GMT+02:00 Stanislav Kocanda <stanislav.kocanda@vanio.cz [19]>:
Ahoj,
díky za odpovědi oběma. Ačkoliv už jsme na aplikaci samotné udělali hodně performance-related úprav a cachujeme jako diví, ještě stále na ní je co zlepšovat a některé dotazy které aplikace vyprodukuje jsou hodně nepěkné. Během srpna máme v plánu stav zlepšit, tak uvidíme. Motivován odpověďmi jsme se pustil do zlepšování konfigurace MySQL a i když už jsem minimálně jednou tento fine-tuning dělal, překvapilo mě, kolik toho bylo špatně (hlavně innodb_buffer_pool_size). Takže po stránce optimalizací snad budeme připravení lépe než loni. :)
Nicméně by mě přesto zajímalo, jaké jsou zhruba limity našich VPS? Chápu, že to je hodně individuální věc, ale alespoň řádově, s průměrnou webovou aplikací v PHP/MySQL a s rozumně nastaveným serverem, na jakou zátěž byste si troufali?
Díky.
Standa
Dne 5.8.2014 20:00, Jaroslav Skřivan napsal:
Jo, sorry. Napsal jsem jen pulku odpovedi, co jsem chtel. Z pohledu I/O operaci zalezi na tom, ktere to jsou.
Pokud mas hodne zapisu, tak to chce zjistit, cim jsou zpusobene. Pokud je vytvari temp tabulky a nejdou zoptimalizovat, tak je staci presunout do tmpfs a mas klid. Pokud se jedna o zapisy aplikace, tak se da upravit innodb_flush_log_at_trx_commit (pouzivas-li innodb, coz bys mel).
Pokud mas hodne cteni, tak potrebujes vic pameti a trochu prekonfigurovat databazi, aby tu pamet vyuzivala. Idealne tak, aby se vsechna data vesla do pameti, pak mysql pri cteni nebude sahat vubec na disk (akorat po startu, aby si vse nacachovala).
Pak zkontroluj indexy, jestli se spravne pouzivaji a jestli je jich rozumne mnozstvi.
Jarda
------ Original Message ------ From: "Jaroslav Skřivan" <skrivy@skrivy.net [10]> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [11]>; "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [12]> Sent: 8/5/2014 7:47:28 PM Subject: Re: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
Hoy,
zkus se zamyslet nad nasazenim cachovani - treba do redisu nebo memcache. V zavislosti na aplikaci se tim da odbourat celkem dost provozu.
Jarda
------ Original Message ------ From: "Stanislav Kocanda" <stanislav.kocanda@vanio.cz [6]> To: "vpsFree.cz Community list" <community-list@lists.vpsfree.cz [7]> Sent: 8/5/2014 7:43:46 PM Subject: [vpsFree.cz: community-list] MySQL a maximální zátěž serveru
> Ahojte, > > rád bych znal váš názor. Na VPS provozujeme web, který > má v září docela zásadní špičku v návštěvnosti > (www.burzaucebnic.net [1]). Loni v září jsme s tím měli > > celkem problémy, jelikož na serveru především MySQL > způsobovala přetížení na diskovém I/O a server chvílemi > kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, > což mi na druhou stranu nepřipadá nijak závratné > číslo). Loni jsme to vyřešili jednak pomocí varnishe, > jednak pomocí úprav samotného webu, kde bylo pár > setsakramentsky problematických dotazů (dibi a > zjišťování počtu záznamů...) a nakonec jsme situaci > stabilizovali. Nicméně momentálně je návštěvnost na > uvedeném webu zhruba dvojnásobná než loni touhle dobou a > já mám obavy, co se v září stane, kolabujícímu serveru > bych se chtěl rozhodně vyhnout. > > Chtěl bych se vás zeptat jakou máte zkušenost s > maximální zátěží VPS, jaký provoz na "normální" > PHP/MySQL aplikaci v pohodě zvládne a co už je problém? > Přemýšlel jsem o tom, že bych si pořídil ještě jednu > VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to > bylo dobré řešení, jelikož by to zase zatížilo síť a > asi by to bylo v průměru pomalejší (i když > předpokládám že nody jsou navzájem propojeny hodně > propustně). Co si o tom myslíte? > > Díky! > > Stanislav Kocanda > > -- Mgr. Stanislav Kocanda > jednatel společnosti Vanio Solutions s.r.o. > > telefon: +420 776 643 433 [2] > e-mail: stanislav.kocanda@vanio.cz [3] > > skype: kocandas > > _______________________________________________ > Community-list mailing list > Community-list@lists.vpsfree.cz [4] > http://lists.vpsfree.cz/listinfo/community-list [5]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [8] http://lists.vpsfree.cz/listinfo/community-list [9]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [13] http://lists.vpsfree.cz/listinfo/community-list [14]
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz [15] http://lists.vpsfree.cz/listinfo/community-list [16]
Links: ------ [1] http://www.burzaucebnic.net [2] http://mail.vanio.cz/tel:%2B420%20776%20643%20433 [3] mailto:stanislav.kocanda@vanio.cz [4] mailto:Community-list@lists.vpsfree.cz [5] http://lists.vpsfree.cz/listinfo/community-list [6] mailto:stanislav.kocanda@vanio.cz [7] mailto:community-list@lists.vpsfree.cz [8] mailto:Community-list@lists.vpsfree.cz [9] http://lists.vpsfree.cz/listinfo/community-list [10] mailto:skrivy@skrivy.net [11] mailto:community-list@lists.vpsfree.cz [12] mailto:community-list@lists.vpsfree.cz [13] mailto:Community-list@lists.vpsfree.cz [14] http://lists.vpsfree.cz/listinfo/community-list [15] mailto:Community-list@lists.vpsfree.cz [16] http://lists.vpsfree.cz/listinfo/community-list [17] http://loadimpact.com/ [18] https://en.wikipedia.org/wiki/ApacheBench [19] mailto:stanislav.kocanda@vanio.cz
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Cau, 4000 pageviews za hodinu je uplne zanedbatelnej provoz... Takze problem bude pravdepodobne v nastaveni MySQL a hlavne v dotazech (chybjejici nebo naopak prebytecne indexy, nevhodne poradi parametru where, spatne navrzeny join, atd...). Za spravnych okolnosti MySQL zadnou velkou zatez v IO nedela - velke mnozstvi IO pozadavku obvykle znamena nejakou z vyse zminenych chyb. Jestli chcete, muzu Vam nabidnout audit aplikace a MySQL serveru + reseni, ale bylo by to placeny, protoze to urcite neni prace na par minut. -- Stanislav Petr glux@glux.org stanislav@petr.email +420 602 620 026 Dne 2014-08-05 19:43, Stanislav Kocanda napsal:
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
Ahoj, 1,11 pageview/sekundu je naozaj malo, to nemoze vytazit VPS. Okrem optimalizacii MySQL configu a pridani pamata k DB by som ja hlavne sustredil na slow query log <http://blog.unitea.sk/post/90141380881/optimalizujeme-a-zrychlujeme-drupal-weby>. Zapni, zbieraj aspon den, idealne tyzden log, spracuj to napr. cez mysqlsla, a vysledne dotazy treba optimalizovat a opakovat dovtedy, kym idealne tento log je prazdny. Keby si s niektorym pomalym query nevedel poradit, ozvi sa a urcite nieco vymyslime ;-) Gusto 2014-08-05 19:43 GMT+02:00 Stanislav Kocanda <stanislav.kocanda@vanio.cz>:
Ahojte,
rád bych znal váš názor. Na VPS provozujeme web, který má v září docela zásadní špičku v návštěvnosti (www.burzaucebnic.net). Loni v září jsme s tím měli celkem problémy, jelikož na serveru především MySQL způsobovala přetížení na diskovém I/O a server chvílemi kolaboval (provoz ve špičce byla cca 4000 pageviews/hodina, což mi na druhou stranu nepřipadá nijak závratné číslo). Loni jsme to vyřešili jednak pomocí varnishe, jednak pomocí úprav samotného webu, kde bylo pár setsakramentsky problematických dotazů (dibi a zjišťování počtu záznamů...) a nakonec jsme situaci stabilizovali. Nicméně momentálně je návštěvnost na uvedeném webu zhruba dvojnásobná než loni touhle dobou a já mám obavy, co se v září stane, kolabujícímu serveru bych se chtěl rozhodně vyhnout.
Chtěl bych se vás zeptat jakou máte zkušenost s maximální zátěží VPS, jaký provoz na "normální" PHP/MySQL aplikaci v pohodě zvládne a co už je problém? Přemýšlel jsem o tom, že bych si pořídil ještě jednu VPS a provozoval na ní pouze MySQL, ale nevím, jestli by to bylo dobré řešení, jelikož by to zase zatížilo síť a asi by to bylo v průměru pomalejší (i když předpokládám že nody jsou navzájem propojeny hodně propustně). Co si o tom myslíte?
Díky!
Stanislav Kocanda
-- Mgr. Stanislav Kocanda jednatel společnosti Vanio Solutions s.r.o.
telefon: +420 776 643 433 e-mail: stanislav.kocanda@vanio.cz skype: kocandas
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
-- s pozdravom Gustáv Pálos
participants (7)
-
Gustáv Pálos -
Jaroslav Skřivan -
Ondrej Galbavý -
Pavel Snajdr -
Stanislav Kocanda -
Stanislav Petr -
Tomáš Valoušek