lze číst i odspodu

Na navigaci | Klávesové zkratky

Jak vybrat správný web hosting

Zákazníkům hledajícím hosting, těm je hej. Mají totiž z čeho vybírat. Ve vodách českého internetu není pro samé hostéry kam plivnout. Kdo je ale pro vás ten nejlepší?

Těžko nad tím uvažovat, pokud zákazníky nerozdělíme alespoň do dvou skupin:

  1. běžný klient, kterého zajímá počet emailových schránek a váhá, zda je lepší 1 GB prostoru za 30 Kč měsíčně nebo 5 GB za dvojnásobek
  2. power user, který bazíruje na tom, jestli je iconv implementován přes libiconv nebo glibc a ošívá se nad použitou verzí Apache, bo trpí banální chybkou

Potřeby běžného a powerovic uživatele jsou místy až protichůdné. Proto je normální, že zatímco jedné skupině určitého kvalitního hostéra doporučím, druhou skupinu před tím stejným musím varovat. Sdělení jako „už rok jsem u XYZ a jsem NAPROSTO spokojený“ jsou tak NAPROSTO bezcenná.

Jedno bych ale zdůraznil: pokud vám současný hostér nevyhovuje, neváhejte a změňte ho! Vůbec to nebolí a je to hotové než bys řekl švec. Naše národní povaha nás zákazníky podvědomě staví do pozice uctivých vlezdoprdelků a podnikatele do role pánů. Kolikrát jste v restauraci nebyli spokojeni a chtěli vrátit jídlo? A kolikrát jste je doopravdy vrátili? A odmítli zaplatit?

Sebevědomý zákazník je solí dobře fungujícího svobodného trhu.

Jste běžný uživatel?

Pak mám pro vás radu: ač si to zatím nepřipouštíte, nejdůležitějším kritériem při volbě hostéra je kvalita zákaznické podpory. Všechny technické parametry jsou druhořadé. Bohužel tuto hodnotu ze žádných tabulek nevyčtete. Určitým vodítkem může být zpracování internetové prezentace (je poslední „novinka“ na titulce tři roky stará?), ale především zkuste zagooglit a přečíst zkušenosti ostatních.

Já vím, zní to jako hodně obecná rada, ale – internet je už pár let zaplaven negativními zkušenostmi s jedním konkrétním hostingem. Každý nový vzlyk pak vypovídá především o plačícím – když si halt neuměl informace vygooglit předtím, tak ať teď trpí a neotravuje ostatní.

Doporučení: hledejte zázemí u (větších) společností s dobrým renomé.

Následující řádky se týkají už jen šílenců.

Jste power user?

Já taky! My pauři to máme těžší v tom, že pro nás je nabídka výrazně chudší. Velcí hostéři zpravidla nevyhoví našim specifickým potřebám a proto je nutné hledat štěstí u těch menších. Mám vyzkoušeno, že hosting provozovaný nadšeným středoškolákem na živnostňák rodičů nemusí být vůbec špatná volba. Ale co když toho chlapce nedejbože srazí auto? One-man-show má jistá rizika.

Pár tipů pro power users:

  • Zjistěte si ve smluvních podmínkách, co přesně znamená „neomezeně“. Jak víme, „věčné časy“ trvaly zhruba 40 let, stejně tak neomezený traffic nebo počet přístupů do databáze může být krutě limitující.
  • Jakou má server konektivitu? (na páteřní lince jsou všichni, to nic nevypovídá)
  • Budete mít přístup k logům?
  • Disponuje šifrovanými kanály SFTP, FTPS, HTTPS, POP3S?
  • Jak často zálohují data? A co vy, jak často zálohujete?
  • Povolí vám .htaccess a mod_rewrite?
  • Jak zdatnou mají webovou administraci?
  • Pozeptejte se jiných power uživatelů na doporučení.
  • A především: dopředu si zjistěte přesné nastavení a konfiguraci software!

Teď budu psát hlavně o PHP. Že by vás přítomnost verze 5.0.5 měla okamžitě odradit, to je asi jasné. Pokud v konfiguraci nenajdete potřebný extension, obvykle se dá domluvit s adminem a modul doinstaluje. Horší je to se záměrným zablokováním některých funkcí přes direktivu disable_functions.

Častou obětí bývá funkce ini_set. Nejsem si sice vědom bezpečnostního rizika s touto funkcí spojeného, ale to třeba vysvětlí někdo zkušenější. Vím však o řadě problémů, které vzniknou právě jejím zablokováním. Dost open-source aplikací tuto funkci používá a bez ní nemusí fungovat korektně nebo vůbec. Někdy lze volání ini_set programátorsky obejít…

ini_set('include_path', $value); // set_include_path($value);
ini_set('max_execution_time', $value); // set_time_limit($value);
ini_set('session.cookie_lifetime', $value); // session_set_cookie_params(...);

…a někdy nelze. Takže zatímco platnost session cookie si nastavíte, tak platnost session souboru nikoliv (direktiva session.gc_maxlifetime). Ironií je, že správné nastavení sessions je důležitým bezpečnostním prvkem, který vám však „bezpečnostní“ vypnutí ini_set odepře.

I když vám podpora hostingu ochotně a pohotově nastaví direktivy dle chuti, problém to kolikrát nevyřeší. Co když jedna aplikace vyžaduje povolené session.use_trans_sid (případ phpMyAdmin), zatímco jiná vyžaduje opak? Někdy pomůže konfigurace PHP na úrovní subdomény nebo adresáře, ale někdy ani to ne (nastavování direktivy track_errors za běhu skriptu apod).

Doporučení: dopředu si zjistěte konfiguraci a výpis phpinfo(). Pak teprve na pár dní hosting bezplatně vyzkoušejte.

Přes web nebo přes operátora?

Mám raději, pokud si úpravy prostředí mohu udělat sám, než abych o ně žádal technickou podporu. Dobrá webová administrace má pro mě cenu zlata. Objektivní důvod je ten, že si modifikaci provedu ihned a nemusím na nikoho čekat. Subjektivně mám vždy pocit, že někoho otravuju. A není divu, když za měsíc hostování platím zlomek toho, co si vezme dělník od lopaty za hodinu práce, tak mi bývá zatěžko chtít ještě něco navíc.

Hodně nápadů jsem nerealizoval jen proto, že jsem nechtěl otravovat. Pokud jste na tom stejně jako já, tak si zjistěte, co všechno lze řešit přes webovou administraci.

Další power tipy

  • Uložte si výstup z phpinfo a občas ho porovnejte s aktuálním stavem. Je dobré mít přehled o všech změnách konfigurace.
  • Logujte si do souboru chyby v aplikaci:
    error_reporting(E_ALL); // nejhorší chyby mívají charakter E_NOTICE
    ini_set('error_log',	  '/path/error.log');
    ini_set('log_errors',	 '1'); // logovat
    ini_set('display_errors', '0'); // ale nezobrazovat
  • Dobří kamarádi jsou Linux, Apache, PHP a MySQL. Windows patří na desktop.
  • Pravidelně zálohuje databázi k sobě.
  • Než týdny maturovat nad složitými pravidly mod_rewrite, osvědčilo se mi následující:
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . index.php [L]

    Robustní controller index.php lze napsat na pár řádků.

Takže, který je ten správný hosting?

Záměrně jsem nechtěl uvádět žádná konkrétní jména. Jistě, mám pár oblíbenců v kategorii „běžný uživatel“ i „power user“. Jenže nemůžu vám je říct. Vy byste tam hned přikvačili, aploudli ty své špatně napsané skripty a můj webík by pak jel ztuha 🙂

Mohlo by vás zajímat

Komentáře

  1. jindra #1

    avatar

    No a dalsi moznosti je poridit si vlastni server. Ja to tak udelal, stoji to necelych 1000 Kc mesicne a muzu si delat co chci, naprosta spokojenost…

    před 17 lety
  2. Lukas #2

    Chtěl bych se zeptat na „Robustní controller index.php“… mod-rewrite totiž řeším stejným způsobem. Díky

    před 17 lety | reagoval [4] David Grudl
  3. Milan Vít #3

    avatar

    Taky jsem se nejprve bál psát kvůli každé (s prominutím) blbosti adminovi, až jsem se s ním skamarádil – tedy další možnost 🙂

    PS: Pokud se šeredně nepletu, tvůj poskytovatel hostingu má docela hezký web 😁

    před 17 lety | reagoval [8] Tonda
  4. David Grudl #4

    avatar

    #2 Lukasi, to je spíš námět na samostatný článek. Napíšu.

    před 17 lety | reagoval [14] Věroš [17] Hds
  5. enoice #5

    avatar

    M4W? 🙂

    před 17 lety
  6. Jakub Vrána #6

    Kde je zakázané ini_set, doporučil bych použít ini_alter 🙂.

    Také jsem šel cestou kamarádova serveru. Nicméně pocit, že ho otravuji, když něco chci, setrval. On to na druhou stranu zase vynahrazuje tím, když mě pošle do serverovny něco připojit, protože z Nového Zélandu to má poněkud daleko…

    před 17 lety
  7. WhiteHat #7

    avatar

    Snažíš se národ naučit správné užívání slovíčka bo? To Ti fandim, ale nevěřim v úspěch :)

    před 17 lety
  8. Tonda #8

    avatar

    #3 Milane Víte, Myslíš webmade.cz nebo tojeono.cz ? :)

    před 17 lety
  9. petr #9

    ty jo, docela mě překvapila včerejší mnohahodinová údržba celého dgx.cz přes špičku a docela by mě zajímalo, co to způsobilo…

    před 17 lety | reagoval [10] David Grudl
  10. David Grudl #10

    avatar

    #9 petře, změnil jsem hosting. Na starém zůstala hláška o údržbě, kterou jsi viděl, dokud se ti nezreplikoval DNS.

    Vlastně jsem ho změnil během dvou dnů podruhé. Nekecám, když říkám, že pokud mi hostér nevyhovuje, neváhám a změním ho 🙂

    před 17 lety | reagoval [11] Langoš [19] Radek Hulán
  11. Langoš #11

    #10 Davide Grudle, Aha, a já si říkal proč se sem dostanu jen skrze anonymizer. Sem se lek, že jsem něco provedl, bububu.
    No, zpátky k tématu.

    před 17 lety
  12. pixy #12

    Robustní kontrolér v PHP místo mod_rewrite? Žirafka tě zabije. 🙂

    před 17 lety | reagoval [14] Věroš
  13. martin #13

    avatar

    Taky bych změnil hosting, ale představa přenášení databáze a souborů mě celkem děsí. Já vím, že pro zdatné jedince to může být rutina a může mě tím i „uzemnit“, ale pokud vyloženě nemusím tak si to nerisknu.

    před 17 lety
  14. Věroš #14

    avatar

    #12 pixy, a cherrypy a drupal (a … doplňte dle vlastní volby) to tak taky dělají a nejspíš vědí proč.

    Problém s mod_rewrite je v tom, že když napáchám větší množství pravidel, tak se v nich nevyznám. Proto oceňuji možnost napsat si vlastní kontroller – přehlednější.

    PAGEMAP = [
    	'/', 'TitlePage', [],
    	'/archiv/([0-9]+)', 'Novinky', ['index'],
    	'/rss/clanky/', 'RssClanky', [],
    	'/rss/vse/', 'RssTitulka', [],
    	'/rss/zpravicky/', 'RssZpravicky', [],
          ...
    ]

    Před prvním spuštěním zkompiluju regexpy do matchovatelného tvaru a pak v nich jenom lineárně vyhledávám a předávám řízení do správného kusu kódu.

    Nějaká stará čísla: matchování cca 150 výrazů – po předkompilování trvá průměrně 0.00017s, zkompilování 0.057s. Jenže kompilacese dělá jenom jednou (máme long-live process), takže ji můžeme v klidu ignorovat.

    Oproti tomu čas strávený kroucením hlavou: „Co jsem tímhle geniálním/úchylným regexpem měl na mysli“, je řádově větší.

    <hr>

    Nezkoušel jsem srovnávat časy mod_rewrite vs sada regexpů, ale pokud člověk neřeší vysokozátěžové weby, tak mu ta konstatní režie nejspíš nevadí. A vysokozátěžové weby zase (předpokládám) neběží na 100% vytížení CPU , neb se distribuují na více strojů.

    #4 Davide Grudle, Ale těším se, až DGX vymyslí něco pěkného čím mne (zase) překvapí 🙂

    před 17 lety | reagoval [18] pixy [21] Dundee [23] pixy
  15. Lick #15

    Konečně někdo kdo používá rewrite mod stejně. Nechápu jedince co se snaží vytvářet několik desítek regulárních dotazů aby odlišili jednu stránku od druhé. Já to dělám tak že celé urlko si naseru do jedné proměné a tu pak pitvám…přecijenom je lepší řetězec rozbíjet funkcema v PHP než dráždit pro každý typ stránky regulární dotaz…zvlášt když člověk potřebuje ošetřit hromady výjimek atd… BTW název „robustní kontroler index.php“ nádherný název vůbec by mě nenapadlo tomu tak hezky říkat… já sem tomu pracovně říkal rozdělovač:o)

    před 17 lety
  16. mottlik #16

    avatar

    pěkný článek, akorát by to chtělo nějaké ty poskytovatele vypsat :)

    před 17 lety
  17. Hds #17

    #4 Davide Grudle, Ten článek by mě hodně zajímal, díky předem :)

    před 17 lety
  18. pixy #18

    #14 Věroši, Nevím, jakou záhadnou myšlenkovou konstrukcí se dá z „Žirafka tě zabije“ vyvodit něco o mě. Já si taky error stránky procesuju přes PHP, ale to přece nikoho nezajímá. Když nevim, o čem je řeč, tak radši mlčim. Naopak Žirafka, dgx a modří vědí…

    před 17 lety | reagoval [20] Věroš
  19. Radek Hulán #19

    avatar

    #10 Davide Grudle, současný hosting každý vidí z whois, mnohem více by mě zajímalo, kdo byl ten předchozí?

    před 17 lety
  20. Věroš #20

    avatar

    #18 pixy, Myšlenkový postup byl následující: Předpokládal jsem, že Žirafka jako webhoster nebude nadšená z někoho, kdo plýtvá strojovými cykly tím, že parsuje URL v interpretovaném jazyce místo toho, aby je „šetrně“ prohnal mod_rewrite v jazyce kompilovaném.

    Tak jsem jen nabídl myšlenku, že processing v interpretovaném jazyce je jednoduchý, má i nějaká pozitiva a používá se. Obzvlášť, když v okolí vidím spoustu lidí, jak s pomocí mod_rewrite řeší každou ptákovinu a je mi z toho smutno.

    Stačí vysvětlení myšlenkových pochodů tak?

    <hr alt="zde prosím odstrihnout">

    O Pixym jsem tam nic nepsal. Pokud tě můj komentář příliš pohoršuje, tak požádej DGX ať ho smaže (a myslím to upřímně…).

    před 17 lety | reagoval [22] pixy [23] pixy
  21. Dundee #21

    avatar

    #14 Věroši, Koukal jsem se do Drupalu, jakym zpusobem to provadi a zaujala mne jedna vec (ale netyka se tematu):

    Drupal casto pouziva koncovky souboru inc, profile atd., ktere jsou podle mne nebezpecne a prezite. Snazi se k nim sice zamezit pristup v .htaccess, jenze to na vsech hostinzich nejde. Prijde mi to jako potencionalni bezpecnostni nedostatek. Jsem pouze paranoidni, nebo muj nazor sdilite?

    Pouziti takoveto zastarale techniky me natolik udivilo, ze sem si az ublognul.

    Bezpecnostni dira v Drupalu

    před 17 lety | reagoval [25] Arthur Dent
  22. pixy #22

    #20 Věroši, Ale ne, prostě to byl soukromý, účelový komentář, na nějž byla každá reakce od nezasvěceného zcela nemístná. Tož tak. 😉

    před 17 lety
  23. pixy #23

    #20 Věroši, Jen pro úplnost, aby bylo jasno: omlouvám se – chyba byla jen v tom, že komentář #14 Věroš byl vložen jako reakce na můj interní fórek. Jinak je to samozřejmě příspěvek přínosný a zajímavý.

    před 17 lety | reagoval [26] Věroš
  24. Arthur Dent #24

    avatar

    Je dobré, pokud povrjůzr poté, co změní hosting, udělá taky patřičné změny v DNS. Například se ukazuje jako vyloženě hloupá myšlenka nechat u předchozího hostéra DNS záznamy a vytvořit nové u nového s tím, že „se to změní v kořenových NS“.

    Pak se taky třeba může stát, že zatímco kus internetu vidí už to nové, tak někteří stále dostávají staré informace z cacheserverů, protože se starý hostér tváří jako autoritativní, takže výsledkem je jen jedno velké 403/404.

    (Právě teď ověřeno, cachens vrací stále NS u gigaweb.cz a to se tváří jako „autoritativní“. Doporučuji zrušit záznam z NS u Gigawebu.)

    před 17 lety | reagoval [27] David Grudl
  25. Arthur Dent #25

    avatar

    #21 Dundee, Ano jsou tam soubory s koncovkou INC. Otázka je následující: Je v nich něco, co by oko nepovolaného nemělo vidět, nebo je tam to, co každý získá stejně jednoduše z instalačního balíčku? ;)

    před 17 lety
  26. Věroš #26

    avatar

    #23 pixy, Pro jistotu: Já se nijak nepohoršuju 🙂 Ve světle dodatečných informací je mi jasné, že jsem reagoval na něco, co tam nebylo. Spíš mne překvapuje, že na českém Internetu je možné, aby se dva lidi dohodli, jak to mysleli…

    (Sakra, a prošvihl jsem jedinečnou šanci mít komentář blízko Pixyho…)

    před 17 lety
  27. David Grudl #27

    avatar

    #24 Arthure Dente,

    ukazuje jako vyloženě hloupá myšlenka nechat u předchozího hostéra DNS záznamy a vytvořit nové u nového s tím, že „se to změní v kořenových NS“.

    Předchozímu hostérovi jsem psal. Dnes znovu. Nic víc s tím asi nenadělám…

    před 17 lety
  28. Jiří Blahút #28

    avatar

    Taky už vás dostal provozovatel hostingu, když jste k němu přenášeli doménu, že vám nezřídil hosting pro doménu a vy jste to zjistili pozdě?? jj, trpká zkušenost, nebudu jmenovat…

    před 17 lety
  29. Poky #29

    avatar

    Máte někdo přehled o tom, kolik českých hostingů dovoluje ukládat skripty mimo kořen webu? Měl jsem zato, že třeba Českýhosting to umí, ale zřejmě jsem se mýlil.

    před 17 lety
  30. tark #30

    avatar

    Možná to umí Coolhosting.cz

    před 17 lety
  31. bpbp #31

    A jak řešíte převod mailových schránek? Ha?
    Běžný klient, malá firma, 15 schránek, schránky IMAP, zbytek POP, vše u hostera A.
    Vy víte, že hoster A a jo spíš posér než hoster a doporučíte migraci k B. Pokud se ale něco po cestě A->B ztratí, sežerou vás.

    Máte nějakou vychytávku na migraci mailů?

    před 17 lety | reagoval [32] Hever
  32. Hever #32

    #31 bpbpe, Všechno to od A postupně postahovat někam, stejnou strukturu vytvořit u B a zase to tam postupně nasoukat. Ideálně přeskočit mezičlánek a tahat přímo a A do B. Někteří mailoví klienti to zvládají. Pokud A je posér, tak asi mo jiných možností nebude.

    před 17 lety

Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.