Hosting a processory

Zdravím, vůbec se v tom nevyznám tak se předem omlouvám...chci si zaplatit hosting a ve specifikacích jsou různé údaje o processorech. Wedos nyní používá 3.8GHz a já našel webhosting, který používá 2x Quad-Core Intel(R) Xeon(R) E5-2609 @ 2.40GHz. Pokud budu jako laik vnímat čísla, budu se domnívat, že 3.8 je víc než 2.4. Ale u toho druhého je 2x. Znamená to tedy 2x 2.4, velkem 4.8???

Ne, ten výstupní výkon se nikdy nerovná přímo dvojnásobku. Co se týče procesorů, ty bych u hostingu řešil až na posledním místě. Pro tebe jsou stěžejní RAM, případně disky aby byly SSD ideálně, konektivita a další aspekty ovlivňující rychlost chodu webových projektů.

Děkuji moc za vysvětlení.---------- Příspěvek doplněn 24.11.2018 v 10:55 ----------Ještě pro upřesnění...u wedosu jsem to nenašel, ale u druhého hostingu ano... zde jsou podrobnosti:SuperMicro(R) ServerMulti-core ProcessorMemory RAM 128GBNetwork Speed 1GbpsCloudLinuxRAID-10 SystemApache + LiteSpeed APISSD MysQL & CachecPanel Multiple PHP-VersionsCageFS SecurityJe to v pohodě?

Neznáme tvůj záměr...

jednoduchý eshop

Pokud to je sdileny hosting, tak rychlost CPU a pocet core je nicnerikajici udaj o vysledne odezve webu

Na co bych se tedy měl poskytovatele hostingu konkrétně ptát? Rychlost CPU a počet core?

Napsal JamuOriginal;1497781

jednoduchý eshop

Pokud je to jednoduchý eshop, jak píšeš, tak tě tyhle údaje zajímat nemusí.

Dobře, děkuji všem za odpovědi.

Zalezi co od toho ocekavas, jak je RS narocny a kolik tam bude soucasnych pristupu - zacni na libovolnem sdilenem reseni a postupne uvidis co a jakWedos -> seriozni sdileny hosting -> slusna VPSka -> dedikovany server - to je hruba bezna cesta

Hlavni je take rict, ze CPU s 3 GHz muze byt pomalejsi nez CPU s 2 GHz. Ghz je jen z mnoha udaju CPU.U hostingu GHz jsou asi tak na 50 tem miste mezi dulezitymi udaji. Hlavni je, v jakem stavu je cela infrastrutura. A nejlepsi zkusenosti, jak zrychlit web je dobre ho navrhnotu a napsat a u eshopu to plati 20ti nasobne.

Ještě výkonově je poměrně důležité, která generace toho Xeonu to je, ale většina hostingů troskotá na nedostatečném IOPS nebo špatné konektivitě.

Jaká je souvislost mezi verzi Xeonu a IOPS?Edit: ve většině případů je spíš problém v tom jak je dána aplikace napsaná, než cokoliv ostatního. Výkony CPU za posledních pár let nerostly o nějaké desítky procent. Konektivita taky není problém - pokud nebereme hosting někoho kdo má jeden dedik s 100mb uplinkem (stačí kouknout třeba na grafy nixu, valná většina DC a velkých housingu & hostingu má overkill uplinky které jedou sotva na 1/4 kapacity) . SSD zlevnily, takže je dnes najdeme skoro všude + řadiče umí taky dobře čarovat s výkonem.Takže vysledek: správně napsaná aplikace, ne jak to dnes dělá mraky vývojářů a všechen jejich bordel v aplikaci radši "umlátí" výkonem než aby trochu optimalizovali.

neexistuje "správně napsaná aplikace" v praxi, spíše by se mělo mluvit o "vhodně napsaná aplikaci", vždy je nutné aplikaci navrhovat vzhledem k provozu a HW, nejsou žádné univerzální aplikace, které vždy běhají rychle.Na sdíleném hostingu by mě daleko více měla zajímat agregace nebo počet klientů/aplikací na jednom serveru. Velká část hostingů kalkuluje s tím, že všichni klienti nebudou využívat HW na 100 % a dávají na jeden server daleko více klientů než by měli pro ideální podmínky. Poté mohu mít na stejné hostingu u jiného webu naprosto jiné rychlosti.Pokud dělám web, který běží přímo na HW a potřebuje dostatek výkonu, frekvence procesoru nebývá tak důležitá (významný význam má třeba v in-memory databázích ala Redis, DNS, BGP). V praxi mě daleko více zajímá počet jader, počet disků, šířka sítě a ve výsledku poměr IO operací a threadů proti výpočetním. To má obrovský význam pokud dělám aplikaci třeba na miliony návštěvníků za minutu, potřebuji mít dostatek jader pro rozložení IO threadů pro network a snížení velikosti TCP tabulek v kernelu v jednom procesu. To jen tak okrajově. V běžné php aplikaci s php-fpm je pro mě daleko důležitější počet jader, i 8 let starý procesor je v jednovláknových operacích dostatečně rychlý pro běžné php aplikace a v čase moc nezrychluje, servové procesy se zlepšují hlavně v počtu jader, šířce instrukcí (512b simd vektorové instrukce vhodné na strojové účetní a statistiku), tepelné efektivitě atd.Php aplikaci může zabít naprostá maličkost, třeba journalový filesystém, který má přetížený journál nebo disk s omezeným iops na čtení (ty nejlevnější stroje v Azure cloudu nejsou vůbec vhodné pro php). Základem rychlé aplikace je měření a zbavování se úzkých hrdel, mohou být naprosto geniálně napsanou php aplikaci, ale pouze 4 souběžné spojení na mysql databázi (např. wedos), při testech se mi stránka načte okamžitě, ale jakmile tam vběhne více lidí, všichni musí čekat. Nebo naprosto rychlá aplikace, který v html hlavičce načítá externí soubor s přetíženého (či vypadnutého) serveru, návštěvník bude na tenhle soubor čekat a nic neuvidí a mohu mít server jakkoliv vyladěný. Výkonnost aplikace se musí řešit komplexně a měřit, měřit a ještě měřit.