Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: Peyton Sharp 25. 10. 2018, 13:34:58
-
Zdravím,
předem bych se chtěl omluvit těm, kterým přijde můj dotaz zbytečný, těm, kdo by mi doporučili googlit atd.. Googlil jsem, ale našel jsem dost protichůdné odpovědi.
Tedy. Jsme eshop, denní návštěvnost máme cca 3000 UIP.
Z důvodu potřeb například ElasticSearche nám nevyhovuje hosting. Na VPS občas narážíme na problémy s výkonem, hlavně IO operace, holt sousedy si nevybereš a i vzhledem k plánovanému rozšíření oboru se kloním k nákupu dedikovaného stroje a jeho následnou virtualizaci (Proxmox) a na něm provozovat jeden virtuál (Debian) a na něm webserver.
Mám trochu v merku koupit zánovní server, něco jako HP DL360 G8, například koupit na www.czech-server.cz, nebo zahraniční podobné obchody.
Kde vidím obrovské rozdíly v cenách jsou užitá CPU, dokonce se často potkáme i s násobky těch cen.
Například stroj s dvěma Xeony, šeštijádro 2.9 GHZ se liší třeba 15 000 Kč oproti osmijádru 1.8 GHZ, který je levnější.
Dále do stroje určitě plánuji SSD disky pro systém a databázi, rotační disky pro zálohy. Určitě pořádný řadič s cache.
Ramku vůbec neuvažuji málo, naopak 32 a více GB, zde ta cena zase tak neroste.
Jde mi o dosažení nejlepší možné odezvy pro klienty, žel díky konfigurátorům, obrovským propočtům dostupností atd...
Má smysl si připlácet za vyšší takt CPU na jádro, nebo to nemá smysl? Určitě není předpoklad takového vytížení naráz z hlediska UIP, ale základní dotaz je, zda se i při třeba 20-30 UIP ve stejný moment ukáže rozdíl.
Vím, že třeba Wedos měl kdysi HP DL380 s CPU 1.8 GHZ, to měl na ta VPSka, ale zde bych chápal i důvod spotřeby, kterou asi dost honí. To já úplně neřeším, jde mi o maximální uživatelský komfort.
Dodám, že mi na serveru každý cca 5 - 10 minut běží dost cronjobů, dost přepočtů atd... Často se reaguje na změnu kurzu v mnoha měnách naráz. Přepočet cen u 60 000 položek nyní trvá třeba 50 sekund. Nerad bych se tedy dostal do toho stavu, že by cronjoby vytáhly všechnu kapacitu pro ostatní uživatele a celé by to bylo horší, jak nyní na hostingu.
děkuji moc za rady, jsem za to vděčný!
-
Píšeš ako keby bol každý web server rovnaký, neuviedol si zásadnú vec: čo ti na tomto stroji vlastne pobeží. Apache? Nginx? Pajara? Node? A databáza? Čo všetko vlastne? Veď od tohto sa má odvíjať konfigurácia, nie od 3000 prístupov denne, veď to je tak málo, že im stíhaš písať response ručne.
-
Pronajmi si na mesic nejaky server, sezen systemaka a budes vedet co a jak dal...
Hodne veci se da poznat i z VPSky - vetsinou jsou programatori hrozny pra.. a problem je v kodu
-
Děkuji za dodatečné dotazy :-)
Webserver by byl Apache, databáze MYSQL(resp. MariaDb). Uvužuji o užití ISPConfigu.
Databáze jedna, ale má nyní 800MB.
Dále ElasticSearch.
Dat, hlavně fotky, je to cca 20GB.
Nyní vše počítám online, až na kategorie, ty používám cache, repsktive data, kterou cronem předpočítám cca co 10 minut.
Pronajmi si na mesic nejaky server, sezen systemaka a budes vedet co a jak dal...
Hodne veci se da poznat i z VPSky - vetsinou jsou programatori hrozny pra.. a problem je v kodu
Já jsem právě programátor, všechen kód píšu sám. V noci my na VPSkách vše jede krásně, když to řeším s poskytovatelem, tak prostě mám to brát tak, že VPS je sdílená služba.
-
Drzet vlastni webserver kvuli eshopu se mi zda zbytecny ... Spis bych se poomrknul po jinem poskytovateli VPS, treba ze vam poskytne nejakou garanci.
-
Od cca 25e/mesic muzes mit slusny server.
Proc se dnes jeste trapit na VPSce?
-
Od cca 25e/mesic muzes mit slusny server.
Proc se dnes jeste trapit na VPSce?
Někde v ČR prosím?
Drzet vlastni webserver kvuli eshopu se mi zda zbytecny ... Spis bych se poomrknul po jinem poskytovateli VPS, treba ze vam poskytne nejakou garanci.
To jsem zkoušel, ale dostal jsem vždy nabídku dedikáče, že na VPS nejde garantovat, nebo slíbit nic.
I z princpu VIP VPS, tedy na jeden stroj dají méně VPSek se může stát, že jsou tam náročnější klienti.
-
Děkuji za dodatečné dotazy :-)
Webserver by byl Apache, databáze MYSQL(resp. MariaDb). Uvužuji o užití ISPConfigu.
Databáze jedna, ale má nyní 800MB.
Dále ElasticSearch.
Dat, hlavně fotky, je to cca 20GB.
Nyní vše počítám online, až na kategorie, ty používám cache, repsktive data, kterou cronem předpočítám cca co 10 minut.
Dobre. Ďalej, čo ten prepočet cien? Prečo trvá 50 sekúnd? To je nejaká query nad MySQL? Ktorá sa vykonáva 50 sekúnd? Lebo to je tiež podozrivé, na prvý pohľad je 60 000 položiek tiež nič extra.
-
Podivej se treba na https://www.hetzner.de/sb
-
Děkuji za dodatečné dotazy :-)
Webserver by byl Apache, databáze MYSQL(resp. MariaDb). Uvužuji o užití ISPConfigu.
Databáze jedna, ale má nyní 800MB.
Dále ElasticSearch.
Dat, hlavně fotky, je to cca 20GB.
Nyní vše počítám online, až na kategorie, ty používám cache, repsktive data, kterou cronem předpočítám cca co 10 minut.
Dobre. Ďalej, čo ten prepočet cien? Prečo trvá 50 sekúnd? To je nejaká query nad MySQL? Ktorá sa vykonáva 50 sekúnd? Lebo to je tiež podozrivé, na prvý pohľad je 60 000 položiek tiež nič extra.
Jo, díky za dotaz.
Řekněme scénář, kde je 60 000 položek, pracuje se třeba s pěti skupinami cen (různí zákazníci). Máme i několik měn, ve které se nakupuje a zároveň 3 měny (czk, usd, Eur), ve kterých se prodává.
K tomu je vždy ještě celkem dost dopočtů, kde se berou v potaz data od dodavatelů ze předem stažených xml feedů, abychom třeba neustřelili v dostupnosti (dodavatel doprodá atd..). Užívám též rozměr času, tedy například v 11 hodin ještě dokážeme ten den zboží odeslat v rámci ČR, ale už ne do SK. V 16 hodin ještě odešleme do Německa, ale jinam už ne třeba. Ve finále je to pár SQL příklazů, ale je to mnoho JOINŮ. Mám celkem vyhráto si s indexy, ale i tak. Těch dotazů je docela mnoho.
Neříkám, že to nejde lépe, to třeba ještě ano, ale 50s je zhruba to, co je pak na ten hosting super výsledek.
Když to samé zkouším na lokálu, kde mám právě k dispozici SSD disky a server s dvěma CPU 2.4 GHZ, spoustu ramky, tak ten skript běží cca půlku času. Ale tam jsem v ten moment sám :-)
-
Podivej se treba na https://www.hetzner.de/sb
zajímavé :-) děkuji.
-
Pronajaty server = vetsi kladivo, kdyz selhava kladivko...
-
Přesto, prosím o vysvětlení, zda i při jednoduchých úkonech je výhoda silnější CPU, nebo se to nevyužije.
-
Vykon CPU v kombinaci RAM a cachovanim pomuze/neublizi.
Neni to ale univerzalni reseni - to by chtelo sledovat zatez primo na serveru a nalezt uzke misto, ktere zpusobuje problemy
-
Děkuji za dodatečné dotazy :-)
Webserver by byl Apache, databáze MYSQL(resp. MariaDb). Uvužuji o užití ISPConfigu.
Databáze jedna, ale má nyní 800MB.
Dále ElasticSearch.
Dat, hlavně fotky, je to cca 20GB.
Nyní vše počítám online, až na kategorie, ty používám cache, repsktive data, kterou cronem předpočítám cca co 10 minut.
Dobre. Ďalej, čo ten prepočet cien? Prečo trvá 50 sekúnd? To je nejaká query nad MySQL? Ktorá sa vykonáva 50 sekúnd? Lebo to je tiež podozrivé, na prvý pohľad je 60 000 položiek tiež nič extra.
Jo, díky za dotaz.
Řekněme scénář, kde je 60 000 položek, pracuje se třeba s pěti skupinami cen (různí zákazníci). Máme i několik měn, ve které se nakupuje a zároveň 3 měny (czk, usd, Eur), ve kterých se prodává.
K tomu je vždy ještě celkem dost dopočtů, kde se berou v potaz data od dodavatelů ze předem stažených xml feedů, abychom třeba neustřelili v dostupnosti (dodavatel doprodá atd..). Užívám též rozměr času, tedy například v 11 hodin ještě dokážeme ten den zboží odeslat v rámci ČR, ale už ne do SK. V 16 hodin ještě odešleme do Německa, ale jinam už ne třeba. Ve finále je to pár SQL příklazů, ale je to mnoho JOINŮ. Mám celkem vyhráto si s indexy, ale i tak. Těch dotazů je docela mnoho.
Neříkám, že to nejde lépe, to třeba ještě ano, ale 50s je zhruba to, co je pak na ten hosting super výsledek.
Když to samé zkouším na lokálu, kde mám právě k dispozici SSD disky a server s dvěma CPU 2.4 GHZ, spoustu ramky, tak ten skript běží cca půlku času. Ale tam jsem v ten moment sám :-)
Jop, to som si aj myslel. Že tam bude veľa JOINov. A to indexami nespravíš, jedine inou štruktúrou, možno nejaký ten VIEW by pomohol tiež, miesto joinovania znovu a znovu...
Ešte jedna vec: aký framework si použil s PHP?
-
Možno by pomohlo rozdeliť úlohy - jeden server pre databázu, druhý pre apache, tretí pre veľké súbory, atď. Tým, že si prácu rozdelia, nemusia to byť žiadne superdelá, ľahšie sa dá identifikovať, ktorý z nich je ako vyťažený a potrebuje posíliť. Navyše je potom ľahšie si prispôsobiť HW na danú úlohu - na DB malé rýchle disky v RAID 0+1, na statické dáta veľké rotačné disky v RAID-5, a pod...
-
Děkuji za dodatečné dotazy :-)
Webserver by byl Apache, databáze MYSQL(resp. MariaDb). Uvužuji o užití ISPConfigu.
Databáze jedna, ale má nyní 800MB.
Dále ElasticSearch.
Dat, hlavně fotky, je to cca 20GB.
Nyní vše počítám online, až na kategorie, ty používám cache, repsktive data, kterou cronem předpočítám cca co 10 minut.
Dobre. Ďalej, čo ten prepočet cien? Prečo trvá 50 sekúnd? To je nejaká query nad MySQL? Ktorá sa vykonáva 50 sekúnd? Lebo to je tiež podozrivé, na prvý pohľad je 60 000 položiek tiež nič extra.
Jo, díky za dotaz.
Řekněme scénář, kde je 60 000 položek, pracuje se třeba s pěti skupinami cen (různí zákazníci). Máme i několik měn, ve které se nakupuje a zároveň 3 měny (czk, usd, Eur), ve kterých se prodává.
K tomu je vždy ještě celkem dost dopočtů, kde se berou v potaz data od dodavatelů ze předem stažených xml feedů, abychom třeba neustřelili v dostupnosti (dodavatel doprodá atd..). Užívám též rozměr času, tedy například v 11 hodin ještě dokážeme ten den zboží odeslat v rámci ČR, ale už ne do SK. V 16 hodin ještě odešleme do Německa, ale jinam už ne třeba. Ve finále je to pár SQL příklazů, ale je to mnoho JOINŮ. Mám celkem vyhráto si s indexy, ale i tak. Těch dotazů je docela mnoho.
Neříkám, že to nejde lépe, to třeba ještě ano, ale 50s je zhruba to, co je pak na ten hosting super výsledek.
Když to samé zkouším na lokálu, kde mám právě k dispozici SSD disky a server s dvěma CPU 2.4 GHZ, spoustu ramky, tak ten skript běží cca půlku času. Ale tam jsem v ten moment sám :-)
Jop, to som si aj myslel. Že tam bude veľa JOINov. A to indexami nespravíš, jedine inou štruktúrou, možno nejaký ten VIEW by pomohol tiež, miesto joinovania znovu a znovu...
Ešte jedna vec: aký framework si použil s PHP?
Ve finále žádný framework, ale vše napsané ručně. Ovladač s PHP je PDO, ale jinak ručně.
Všechny frameworky byly na mě moc pomalé a robustní. Nepopírám též to, že si raději něco napíšu, než řešit to, kde je zakopaný pes.
-
Hm. Koľko web aplikácií si napísal pred tým eshopom?
-
Hm. Koľko web aplikácií si napísal pred tým eshopom?
15 let jsem se tím živil, pak jsem se "vrátil" do naší rodinné firmy.
-
Hm. Koľko web aplikácií si napísal pred tým eshopom?
určitě uznávám, že kdybych se do nějaké frameforku více zažral, nebo si nastudoval nějaké light framoworky, tak bych třeba to viděl jinak a viděl bych i výhody jejich, ale když si řeknu, že skoro všechno je "pár selectů" do db, tak to je pak cesta, jak se vše zvětšuje, omptimalizuje, ale jít a vše přepsat by bylo na tolik tolik času a jaká by byla toho všeho výhoda? To je lepší jít a naprogramovat nějaký konfigurátor, to pak je na podnikání vidět, protože jej lidé užívají a objednávají, ale přepis celého webu, kde je průměrná stránka vygenerována za 0,04 nyní mi smysl moc nedává.
Jak jsem psal, dlouho trvají cronjoby. Nyní chceme užít ten elasticsearch třeba, tam již s hostingem nejde užít.
VPS jsem byl jak na houpačce. Někdy ok, ale někdy člověk neví, proč je to pomalé, když já nic nevytěžuji.
-
Hm hm hm... Problém je, že si myslím, že nepotrebuješ nový hosting, už vôbec nie vrážať desať tisíce do servera a drahšieho server housingu. Zatiaľ to vyzerá, že výkon by výrazne vylepšilo predovšetkým prekopanie aplikácie a databázy, ich optimalizácia... Ktorý je to eshop? Daj mi link.
-
De facto dost je třeba nestálost výkonu VPS vidět na tom živém vyhledávání, tedy realtime šahání do DB, kde uživatel musí vidět okamžitou reakci.
Hm hm hm... Problém je, že si myslím, že nepotrebuješ nový hosting, už vôbec nie vrážať desať tisíce do servera a drahšieho server housingu. Zatiaľ to vyzerá, že výkon by výrazne vylepšilo predovšetkým prekopanie aplikácie a databázy, ich optimalizácia... Ktorý je to eshop? Daj mi link.
V tento moment není online redesign a částečný přepis toho webu, současný je www.kocarky.cz
-
Rozdeleni uloh sice pomuze, ale za cenu sitove latence. Dival bych se timto smerem:
1] zatizeni disku pri vypoctech
2] v cem jsou napsane vypocty (napr. php5 je sakra pomale proti php7)
Pokud se jedna o mensi objemy dat, tak se hodi mit tolik RAM, ze je db defakto nacachovana. Jinak podle poctu procesu (vm, apod), spis preferuji vyssi GHz nez vice jader, pokud neni nutna extremni paralelizace.
-
Tak, já bych nejprve zkouknul ty Joiny, jestli to nejde lépe optimalizovat....velice často někdo tvrdí, že to je všechno ok, ale když se pak na to podívám, tak je tam nějaká výkonnostní bota. Na 60000 řádcích by to mělo při všechno fičet.
-
Hm hm hm... Problém je, že si myslím, že nepotrebuješ nový hosting, už vôbec nie vrážať desať tisíce do servera a drahšieho server housingu. Zatiaľ to vyzerá, že výkon by výrazne vylepšilo predovšetkým prekopanie aplikácie a databázy, ich optimalizácia... Ktorý je to eshop? Daj mi link.
Zde trochu narazím, nikdo mi na hosting nenainstaluji nic na server, třeba to elastic search.
-
De facto dost je třeba nestálost výkonu VPS vidět na tom živém vyhledávání, tedy realtime šahání do DB, kde uživatel musí vidět okamžitou reakci.
Hm hm hm... Problém je, že si myslím, že nepotrebuješ nový hosting, už vôbec nie vrážať desať tisíce do servera a drahšieho server housingu. Zatiaľ to vyzerá, že výkon by výrazne vylepšilo predovšetkým prekopanie aplikácie a databázy, ich optimalizácia... Ktorý je to eshop? Daj mi link.
V tento moment není online redesign a částečný přepis toho webu, současný je www.kocarky.cz
Hm! Je to pekné. Neresponzíve, za to máte od Google body dole, ale inak pekné. Len si vážne myslím, že tam toho nemáš tak moc, aby to išlo pomaly. Navyše ak to dobre chápem, stránky sa ti generujú rýchlo, že problém máš len s tými cronmi. Chce to fakt len reštruktúrovať dáta a optimalizovať query.
-
De facto dost je třeba nestálost výkonu VPS vidět na tom živém vyhledávání, tedy realtime šahání do DB, kde uživatel musí vidět okamžitou reakci.
Hm hm hm... Problém je, že si myslím, že nepotrebuješ nový hosting, už vôbec nie vrážať desať tisíce do servera a drahšieho server housingu. Zatiaľ to vyzerá, že výkon by výrazne vylepšilo predovšetkým prekopanie aplikácie a databázy, ich optimalizácia... Ktorý je to eshop? Daj mi link.
V tento moment není online redesign a částečný přepis toho webu, současný je www.kocarky.cz
Hm! Je to pekné. Neresponzíve, za to máte od Google body dole, ale inak pekné. Len si vážne myslím, že tam toho nemáš tak moc, aby to išlo pomaly. Navyše ak to dobre chápem, stránky sa ti generujú rýchlo, že problém máš len s tými cronmi. Chce to fakt len reštruktúrovať dáta a optimalizovať query.
Děkuji, ten Google mě nebolí tolik, jako uživatelé. Máme 65% přístupu z mobilů. Proto redesign hlavně přináší responsivitu, toť hlavní motivace redesignu.
Načítání stránek je ok, i ty cronjoby, že jdou delší dobu nevadí, ale jde o to, že chci ten elastic search, chci užívat na serveru program na lepší práci s kompresi fotek, to mi hosting nedá samozřejmě. VPS co jsem zkoušel, tam jsem vždy narazil na to, že výkon není stále stejný. Ano, dedikač by se většinu dne kopal do zadku, ale pokud by lepší výkon, lepší hledani... Kdyby každý den toto přineslo zisk 1 000 Kč navíc, pak je nějaký rozumný stroj i housing brzy zaplacen. Když by se udělalo rozumné zálohování, tak v případě havárie serveru by se nechalo i celkem rychle (za pár hodin) případně sehnat jiný, podobný stroj a jet na něm. Sice jsem moc mrtvých hw na servery neviděl, ale stát se může vše.
-
Fyzicky server + Proxmox + Shop jako VPSka, druha VPSka jako devel prostredi apod.
A zalohovani denne na lokalni disk a pro sichr domu na NASku
A behem nekolika hodin to rozjedes znova na novem HW kdekoli jinde...
-
Fyzicky server + Proxmox + Shop jako VPSka, druha VPSka jako devel prostredi apod.
A zalohovani denne na lokalni disk a pro sichr domu na NASku
A behem nekolika hodin to rozjedes znova na novem HW kdekoli jinde...
,
Jo, takovou jsem měl i představu cca.
Mám do firmy supr konektivitu. 100/100 1:1. Optika az ke switchi, takže ping třeba na seznam je 2ms.
-
Fyzicky server + Proxmox + Shop jako VPSka, druha VPSka jako devel prostredi apod.
A zalohovani denne na lokalni disk a pro sichr domu na NASku
A behem nekolika hodin to rozjedes znova na novem HW kdekoli jinde...
,
Jo, takovou jsem měl i představu cca.
Mám do firmy supr konektivitu. 100/100 1:1. Optika az ke switchi, takže ping třeba na seznam je 2ms.
Server pronajmi - nezestarne, neresis chyby HW, snadno upgradnes a nemusis ani chladit
-
Načítání stránek je ok, i ty cronjoby, že jdou delší dobu nevadí, ale jde o to, že chci ten elastic search, chci užívat na serveru program na lepší práci s kompresi fotek, to mi hosting nedá samozřejmě. VPS co jsem zkoušel, tam jsem vždy narazil na to, že výkon není stále stejný. Ano, dedikač by se většinu dne kopal do zadku, ale pokud by lepší výkon, lepší hledani... Kdyby každý den toto přineslo zisk 1 000 Kč navíc, pak je nějaký rozumný stroj i housing brzy zaplacen. Když by se udělalo rozumné zálohování, tak v případě havárie serveru by se nechalo i celkem rychle (za pár hodin) případně sehnat jiný, podobný stroj a jet na něm. Sice jsem moc mrtvých hw na servery neviděl, ale stát se může vše.
Vyzkoušej https://cloudimage.io/ (https://cloudimage.io/) a máš po problémech se zpracováním fotek. Utáhne ti to pak i obyčejný webhosting.
-
Načítání stránek je ok, i ty cronjoby, že jdou delší dobu nevadí, ale jde o to, že chci ten elastic search, chci užívat na serveru program na lepší práci s kompresi fotek, to mi hosting nedá samozřejmě. VPS co jsem zkoušel, tam jsem vždy narazil na to, že výkon není stále stejný. Ano, dedikač by se většinu dne kopal do zadku, ale pokud by lepší výkon, lepší hledani... Kdyby každý den toto přineslo zisk 1 000 Kč navíc, pak je nějaký rozumný stroj i housing brzy zaplacen. Když by se udělalo rozumné zálohování, tak v případě havárie serveru by se nechalo i celkem rychle (za pár hodin) případně sehnat jiný, podobný stroj a jet na něm. Sice jsem moc mrtvých hw na servery neviděl, ale stát se může vše.
Vyzkoušej https://cloudimage.io/ (https://cloudimage.io/) a máš po problémech se zpracováním fotek. Utáhne ti to pak i obyčejný webhosting.
Ale na fotkách to podle všeho nestojí. Nemůžou to blokovat právě ty cronjoby (izolace transakcí, zámky...)? Já bych nasimuloval zátěž (jmeter nebo něco podobného) a zaměřil se na analýzu úzkého hrdla. Zkoumal bych, kolik server unese s cronjobama a bez nich. Samozřejmě někde v testovacím prostředí, ne v produkci.
Dedikovaný server si můžete pronajmout i na zkoušku, a taky není VPS jako VPS.
-
V cem jsou napsane ty cronjoby? Kde je vypocetni logika - ve skriptu nebo v db? Jaka je zatez db pri vypoctech, resp. jake jsou zakladni parametry (zamky apod)?
-
Chápu ten problém s VPS. Jako zákazník opravdu nemůže vidět samotné vytížení toho fyzického stroje (CPU, diskového SSD pole etc.). Dále si také kupuje výkon v počtu vláken CPU a už v podstatě není na něm a mnohdy ani neví, na jakém a jak starém CPU to na konec poběží.
V každém případě pro Váš use case by VPS mělo stačit, jen si musíte vybrat dodavatele se kterým se jasně domluvíte na jakém fyzickém stroji to poběží a ideálně si třeba vyhradit vlastní diskové pole (to taky není problém domluvit), abyste IO měl operace jen pro sebe.
Na samotné zrychlení stránek, pak může (mimo jiné) pomoci využít služeb nějaké CDN a statický obsah do ní cachovat.
-
Jinak bych se asi osobně úplně vyhnul myšlence kdy všechno "nacpete" do jednoho fyzického serveru, včetně rotačních disků pro zálohy. Z hlediska risk managementu je to časovaná bomba - zvláště pak když vám na tom fyz. serveru odejde nějaká fyz. součástka a vám může trvat i pár dní ji sehnat.
Pokud Vás ten Eshop živí - tak určitě zálohovat vše na jiný server, který bude v jiné lokalitě (úplně ideálně mít úložiště i DB v clusteru, tak aby mohl běžet záložní web server někde jinde). Vzpomeňme na případy kdy do DC natekla voda a bylo po serverech...
-
já měl hosting za 120 Kč ROČNĚ vč. domény (nebudu dráždit blokovače reklam a REKLAMU neudělám)
-
Není pravdou, že uživatel VPS nevidí, zda je nebo není hypervizor přetížen. Linux na skvělé nástroje na monitorování výkonu. Třeba na iostat je vidět, zda je disk, ač virtuální, zatížený, nebo zda má velké latence operací. Zákazníka nemusí zajímat důvod, ale může si opatřit důkazy a žádat nápravu. Stejně tak přetížený procesor hypervizoru prozradí kolonka Steal v top. Všechny tyto hodnoty jdou grafovat vhodným nástrojem, např. collectd nebo monitorix.
V připadě, že byste chtěl poradit s výkonem, hoďte si kopii e-shopu k nám na VPS a s optimalizací Vám poradíme.
-
Není pravdou, že uživatel VPS nevidí, zda je nebo není hypervizor přetížen. Linux na skvělé nástroje na monitorování výkonu. Třeba na iostat je vidět, zda je disk, ač virtuální, zatížený, nebo zda má velké latence operací. Zákazníka nemusí zajímat důvod, ale může si opatřit důkazy a žádat nápravu. Stejně tak přetížený procesor hypervizoru prozradí kolonka Steal v top. Všechny tyto hodnoty jdou grafovat vhodným nástrojem, např. collectd nebo monitorix.
V připadě, že byste chtěl poradit s výkonem, hoďte si kopii e-shopu k nám na VPS a s optimalizací Vám poradíme.
Nekdy jo, a jinde ne - a odpust si reklamu/self promo