Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: aigor.net 10. 04. 2018, 14:09:13
-
Možná hloupá otázka - nechci řešit flame, pořádně ani neznám rozdíly z pohledu správy serveru, ale jako web-develeper musím řešit nastavení jako forward, hlavičky, apod.
Poslední dobou je toho čím dál víc, co je vázáno na konkrétní server.
Ovšem ve většině případů vás webhosting nenechá hrabat v konfiguraci, často i triviální změna je zdlouhavý proces se schvalováním (což se dá leckdy pochopit).
Zatím sem spokojeně používal Apache, hlavně kvůli .htaccess kde si nastavím co potřebuju (i když výkon je pak trochu jinde), ale na jednodušší webhosting je to rychlé, funkční a plně ve vlastní režii.
Teď narážím na nginx, kde se dost věcí musí řešit přes support zásahem do konfigurace.
Jaké máte zkušenosti, resp. doporučení co upřednostnit. Omezení, možnosti, výhody a nevýhody..?
Prosím bavme se jen o situaci "píšu někomu stránky na hosting", kdy můžu maximálně doporučit změnu webhostingu.
-
a neni lepsi misto web hostingu pouzivat vps a tam si provozovat vlastni web server?
-
a neni lepsi misto web hostingu pouzivat vps a tam si provozovat vlastni web server?
Jak kdy. Pro mnoho případů užití běžný webhosting prostě stačí.
-
Zatím sem spokojeně používal Apache, hlavně kvůli .htaccess kde si nastavím co potřebuju (i když výkon je pak trochu jinde), ale na jednodušší webhosting je to rychlé, funkční a plně ve vlastní režii.
Teď narážím na nginx, kde se dost věcí musí řešit přes support zásahem do konfigurace.
Pokud je .htaccess do cca 10 řádek, tak to má na výkon zpravidla jen zanedbatelný vliv.
Pokud chceš kvůli zlepšení výkonu použít Nginx, asi budeš muset jít do zmíněného VPS, který ti pak bude moct nabídnout spoustu dalších zajímavých služeb, o kterých si na webhostingu můžeš nechat jen zdát.
-
.htaccess je poměrně zoufalost, žere to výkon na každém kroku.
Na druhou stranu, vývojář nemusí kooperovat se správcem serveru.
Pro malé aplikace (= s malým zatížením), nebo aplikace s krátkou životností je Apache a .htaccess v pohodě.
Nginx nutí víc dělat věci "správně" a daný postup dává možnost i správci vyjádřit se k aplikaci. Vývojáři jsou čuňátka, na stejný virtualhost rvou statický obsah i scripty, neumějí řešit nastavení parametrů pro cachování atd. atd. Z toho důvodu je u větších projektů vždy nutné, aby vývojář kooperoval se správcem. V ten moment není nginx vůbec na překážku a jen přináší výhody.
Doporučuji jít cestou nginxu, z nginxu se dá vždy lehce přejít a vyprasit nastavení do .htaccess na apachi. Opačně to bolí víc.
-
To jsou zase moudra... Statický obsah na stejným virtualhostu nevadí vůbec ničemu.
-
To jsou zase moudra... Statický obsah na stejným virtualhostu nevadí vůbec ničemu.
No, tak na to se zeptejte nějakého admina. Ono je dost nepřehledné nastavovat např. exspirace nebo statickou kompresi (předkompresi) nebo cache jen na určité adresáře. Daleko příjemnější, přehlednější a tím pádem i méně náchylné na chyby je to oddělit. Programátora takový ohled nestojí prakticky žádnou práci a pomůže to při správě. Neříkám, že to nejde mít naházené v jednom, ale nepřináší to nic navíc.
-
To jsme se zase dostali trochu jinam...
Primárně jsem zaměstnanec jinde, ale občas někdo chce vypomoct s prezentací, něco i jednorázově opravit, nasadit novej web, CMS,... Určitě všichni tohle znáte "hele řekni Pepovi, on to umí.."
Kdybych se někdy utrhl na plnej job, tak jdu do VPS a není co řešit.
Takto se cca z 50% potýkám s nejrůznějšími webhostingy, u 40% můžu i ovlivnit kam to registrují a 10% jsou korporátní saláty většinou na IIS a podobný kompost.
U webíku typu "prodej štípaného dřeva", nebo "TJ Chvojkovice-Brod" absolutně nemusím řešit výkon při extrémní zátěži.
Přístup k htaccess mě u Apache umožní prakticky vše si nastavit kdykoliv "na počkání", proto jsem ho zatím vždy preferoval. Nemám nic proti nginxu, podle posledních prezentací se mi docela líbí, ale buď mi něco podstatného uchází, nebo to prostě není úplně nejšťastnější volba pro webhosting, pokud si vývojář nemůže nastavit co potřebuje.
Než se dohadovat s podporou (a někdy je to povídání na samostatný článek), je pro mě snazší dotyčného přesvědčit ke změně hostingu, nebo prostě pomoc odmítnout.
Abych se ujistil, že není problém mezi židlí a klávesnicí, ptám se povolanějších, kteří mají větší zkušenosti, jak k podobným věcem přistupovat..
-
Přístup k htaccess mě u Apache umožní prakticky vše si nastavit kdykoliv "na počkání", proto jsem ho zatím vždy preferoval. Nemám nic proti nginxu, podle posledních prezentací se mi docela líbí, ale buď mi něco podstatného uchází, nebo to prostě není úplně nejšťastnější volba pro webhosting, pokud si vývojář nemůže nastavit co potřebuje.
Neuchází Vám nic. Nginx opravdu jde měnit jen změnou konfigurace a reloadem. Stejně tak Apache, když vypnete podporu .htaccess (což se vypíná právě tam, kde jde o výkon nebo z principu).
Pro popsaný účel není jiná alternativa než Apache + .htaccess, je to jediná možnost něco nastavovat bez přístupu ke konfiguraci serveru a bez reloadu celého webserveru.
-
Jinak důvody, proč nginx nepodporuje a nechce podporovat nic podobného, jako je .htaccess, jsou popsány zde:
https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/
-
Jinak důvody, proč nginx nepodporuje a nechce podporovat nic podobného, jako je .htaccess, jsou popsány zde:
https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/
Všichni víme, jak demagogická tvrzení tam jsou, ale stejně musí ten odkaz někdo stále opakovat.
-
Všichni víme, jak demagogická tvrzení tam jsou, ale stejně musí ten odkaz někdo stále opakovat.
Minimálně je cenný v té rovině informace, že nginx nic takového nepodporuje a podporovat nebude.
-
Neni hosting jako hosting. Rosti.cz pouziva Nginx a jeho konfigurace je plne v moci uzivatele.
-
nj, ono by stačilo možná něco jako "klikací" form obvyklých nastavení, kterej jim nageneruje příslušnou konfiguraci a ta se během XX hodin reloaduje. Za mě by to bylo naprosto dostačující řešení a pro hosting taky usnadnění (za předpokladu, že si to napíšou správně...)
-
nj, ono by stačilo možná něco jako "klikací" form obvyklých nastavení, kterej jim nageneruje příslušnou konfiguraci a ta se během XX hodin reloaduje. Za mě by to bylo naprosto dostačující řešení a pro hosting taky usnadnění (za předpokladu, že si to napíšou správně...)
Takto to má řešené např. Plesk Onyx panel. Ale reload se prostě provést musí.
-
To jsou zase moudra... Statický obsah na stejným virtualhostu nevadí vůbec ničemu.
Pokud se jednou rozhodnete statický obsah odbavovat CDNkou, tak mít statický obsah na nějaké subdoméně Vám ušetří dost práce. Ale nutnost to samozřejmě není. U velkých projektů to ale dává smysl ( často je odbavování statického contentu odbavováno jinými servery než obsah dynamický a odělit to na úrovni subdomény je na loadbalancerech mnohem levnější operace než když to řešíte regulárními výrazy podle koncovky souboru, jména adresáře nebo nedej bože content type )
No a čistě technicky - apache se zapnutým .htaccess:
/var/www/mojedomena.cz/web <- root webu
v něm obrázek:
/var/www/mojedomena.cz/web/images/thumbnails/2018/1.png
Pokud nevypnu zpracování .htaccess pro adresář images, tak při requestu na tenhle soubor se bude hledat soubor .htacess v adresáři web, images, thumbnails a 2018 -> udělám úplně zbytečně 4 read requesty na disk než ten obrázek přečtu.
Takže .htaccess je pro vývojáře nesmírně pohodlný, ale je vhodné si uvědomit co to vlastně dělá. A například pro adresáře kde vím že .htacces nebudu potřebovat si ho nechat vypnout ( AllowOverride None ). Až ten web jednou vyroste a bude mít velkou návštěvnost, tak tyhle drobné optimalizace mohou šetřit nějaké peníze.
-
Pokud nevypnu zpracování .htaccess pro adresář images, tak při requestu na tenhle soubor se bude hledat soubor .htacess v adresáři web, images, thumbnails a 2018 -> udělám úplně zbytečně 4 read requesty na disk než ten obrázek přečtu.
Ty requesty vyřídí cache, k disku to ani nedojde.
-
Ty requesty vyřídí cache, k disku to ani nedojde.
Pořád je to io stat, který stojí CPU cykly a drží aktivní cache. Na serverech je to ve větším opravdu znát. Je jedno, že to chytí cache. Ta cache může v tu samou dobu dělat jinou, smysluplnější práci.