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,pomocou http://loadimpact.com/ [17] alebo
navrhujem ten server zatazit vopred a otestovat konfiguraciu :) Napr
https://en.wikipedia.org/wiki/ApacheBench [18]<stanislav.kocanda@vanio.cz [19]>:
Ondrej
2014-08-05 23:42 GMT+02:00 Stanislav Kocanda
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 ------<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,(www.burzaucebnic.net [1]). Loni v září jsme s tím měli
rád bych znal váš názor. Na VPS provozujeme web, který
má v září docela zásadní špičku v návštěvnostitelefon: +420 776 643 433 [2]
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.
e-mail: stanislav.kocanda@vanio.cz [3]Community-list@lists.vpsfree.cz [4]
skype: kocandas
_______________________________________________
Community-list mailing list
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