HW a CPU pro webserver

[Peyton Sharp]

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ý!

[Reklama]

[Wal-De-Mar]

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.

[Vilith]

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

[Peyton Sharp]

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.

[kolega]

Drzet vlastni webserver kvuli eshopu se mi zda zbytecny ... Spis bych se poomrknul po jinem poskytovateli VPS, treba ze vam poskytne nejakou garanci.

[Reklama]

[Vilith]

Od cca 25e/mesic muzes mit slusny server.

Proc se dnes jeste trapit na VPSce?

[Peyton Sharp]

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.

[Wal-De-Mar]

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.

[Vilith]

Podivej se treba na https://www.hetzner.de/sb

[Peyton Sharp]

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 :-)

[Peyton Sharp]

Podivej se treba na https://www.hetzner.de/sb

zajímavé :-) děkuji.

[Vilith]

Pronajaty server = vetsi kladivo, kdyz selhava kladivko...

[Peyton Sharp]

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.

[Vilith]

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

[Wal-De-Mar]

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?