Diskuze: Důležitost backendu

Stanislav Lamoš

Člen

Stanislav Lamoš:2.1.2017 22:07

Zdravím,

mám dotaz ohledně vývoje webových stránek. Teprve s tím začínám a učím se podle tutoriálů tady na ITnetworku. Chtěl bych se zeptat jak velkou roli hraje při celkové funkčnosti a rychlosti načítání stránek backend (PHP, JavaScript)? Je možné napsat funkční a použitelný web pouze pomocí HTML a CSS?

Děkuji mockrát za odpověď

Odpovědět

2.1.2017 22:07

Marian Benčat

Člen

Marian Benčat:2.1.2017 22:14

Toto je strašně složité říci, jelikož to ovlivňuje strašně moc faktorů. Obecně lze ale říci, že staticke webové stranky se dnes už moc nenosi a pokud by ti šlo o rychlost backendu (coz často nejde) tak PHP je pořád tragicky pomalé úplně na vše.

Nahoru Odpovědět

2.1.2017 22:14

Totalitní admini..

Lava

Člen

Lava:3.1.2017 7:21

V bežnom živote:
Vieš urobiť webstránku iba pomocou html a CSS. Samozrejme, môže vyzerať pekne, ale nikdy nebude na nejakej vysokej úrovni, môže to byť maximálne prezentačný web, kde sa nič nebude meniť. Predstav si, ako robíš v čistom html a CSS eshop a na každý tovar vytváraš zvlášť pdostránku. Navyše by bolo bez PHP nemožné objednať, odoslať e-mail, alebo hocičo iné.

Čo sa týka rýchlosti back-endu, tak to by som nejako neriešil. Pokiaľ nemáš gigantickú aplikáciu, tak zrejme to ani nepostrehneš. Najviac spomaľujú volania databázy, čiže ak chceš na stránke zobraziť miliardu nejakých článkov z DB, tak to potrvá. Lenže to nie je vec PHP. Každopádne, Facebook, Wikipedia, Travian,... to všetko sú obrovské projekty, ktoré fungujú na PHP a nezdajú sa mi nejako pomalé. Napriek tomu, že servery sú na druhej strane planéty. Takže toto by som vôbec neriešil, čo sa týka rýchlosti spracovania.
Pokiaľ je appka urobená dobre, bude rýchlo jehať hoc aj na jave. Ja mám skúsenosť len s jednou appkou, ktorá má back-end na jave, je to toto:
http://www.footballaustralia.com.au/
Javovský padelek, ktorý sa stále načítava pol minúty... Našťastie toto už je dávno za mnou

Nahoru Odpovědět

3.1.2017 7:21

Aspartám, sacharín, to je môj vitamín

Marian Benčat

Člen

Marian Benčat:3.1.2017 10:41

Toto je problém vás PHPkářů. Hlavně, že jste dali mínusy,.. ale argumenty pro své tvrzení samozřejmě nemáš žádné.

Wikipedia je jen output z databáze, PHP tam jen bere data a vyflusne je do templaty, není tam tedy žádná práce samotného runtime.
Facebook NEJEDE a NIKDY nejelo na PHP, už to prosím konečně pochopte a přestaňte to dávat jako příklad nějaké efektivnosti PHP, pouze tím dáváte najevo, že tomu vůbec nerozumíte.

PHP na facebooku mělo opět za úkol pouze "frontendovou část", tedy vzít zpracované data a šoupnout je do šablony. Nic víc. Ta skutečně náročná výpočetní část facebooku - to silné, co dělá sociální síť sociální sítí v PHP nikdy nebyo a ani nebude. Navíc - Facebook velmi brzo zjistil, že i na rendering je PHP super pomalé a tedy si musel udělat HHVM, které nyní navíc už nahraidl vlastním Hackem.

Backend facebooku je tedy napsaný v Javě, C/C+, a část v modifikovanym Erlangu .

Samozřejmě máš pravdu v tom, že u běžného webu stráví většinu času nad I/O operacema. U větších webů, to ale už tak není. A tam se ukáže, že je PHP mnohem, mnohem pomalejší.. A nemám na mysli žádné atomové výpočty.

Zkoušel jsis někdy třeba seřadit v PHP a Javě 100milionu prvku nějakým zajímavějším algoritmem? Zjistil by si, že mto PHP trvá 2 minuty, kdežto ostatním 2 vteřiny a hlavně,.. že musíš přikoupit paměti, protože ti PHP sežere 2 GB.

Editováno 3.1.2017 10:43

Nahoru Odpovědět

3.1.2017 10:41

Totalitní admini..

Lava

Člen

Lava:3.1.2017 10:44

Travian je komplet celý na PHPčku a podľa mňa robí brutálne výpočty, brutaljnejšie ako FB aj keď ich je menej. A stíha, sem-tam dačo padne, ale nie je to nič strašné. Očividne človek, ktorý sa učí HTML určite nerozmýšľa o zoradzovaní sto mega prvkov v jave a v php... :-/

Nahoru Odpovědět

3.1.2017 10:44

Aspartám, sacharín, to je môj vitamín

Marian Benčat

Člen

Marian Benčat:3.1.2017 10:46

Já nevím co se provádí za výpočty na Travianu. Osobně si myslím, že to technologické zázemí bude poměrně staré a to co potřebují zpracovat jsou velká data, takže bych se nedivil, kdyby to měli z největší části jako Stored procedury nad databází.

Ty máš samozřejmě pravdu v tom, že většinou neřešíš výkon runtime na serveru a pokud řešíš, tak je to nejčastěji chybou programátora. To ale není důvod neuznat něco co je pravda a sice, že PHP je extrémně pomalé.

Což je něco na co se on ptal:

rychlosti načítání stránek backend (PHP, JavaScript)?

pokud tedy s tím neosuhlasíte, nic nebrání tomu si udělat nějaké výkonnostní testy.

Nahoru Odpovědět

3.1.2017 10:46

Totalitní admini..

Aleš Lulák

Člen

Aleš Lulák:3.1.2017 12:24

Za mě je teda odpověď jednodušší. Ano je to možné, ale ovšem záleží na složitosti stránek.

Statické stránky se dodnes nosí. Pokud jde o nějakou jednodušší prezentaci, proč ne. Pravdou je, že ale i u jednodušších prezentací chceme aby nás lidi mohli kontaktovat, nebo komentovat, nebo vyplnit dotazník apod. V tom případě pak už potřebujeme backend. Backend nějak sám musí pracovat, takže tam milisekundy zdržení bude (záleží na jak na jazyku, tak na server, tak jeho výkonu). Otázka je spíš teda pro Tebe, co od webu očekáváš. A pokud se jen učíš se zájmem to znát, nauč se vše, co si myslíš, že se bude hodit.

(dál už je to nepotřebný)

Pokud budeme mluvit o jazycích tak PHP je, ano, pomalejší, ale od verze 7 šlape celkem dobře. Pro malé weby je to v pohodě. Mně se nelíbí protože je prostě ošklivé a na všechno je tam funkce a ne objekt. Výhoda je to, že je to tak rozšířené, že je to všude. Existuje tuna hotových redakčních systémů a další tuna rad a návodů. Ale taky je to otázka bezpečnosti, na co všechno si dát pozor.

Já osobně jsem pro Node.js, což je "javascript na backendu". Výhoda je, že pokud se naučíš JavaScript, tak se Ti bude jednodušše přecházet na backend, jen se naučíš další funkce (a jiné zapomeneš :-)) . A ano, ten je rychlý. Funguje i jako vlastní web server.

Pak jsou další alternativy jako asp.NET, nebo již zmiňovaná Java (fuj, tu já ale rád nemám). Taky jsou tu taky dost používané frameworky Django pro Python a Ruby on Rails. Ale co jde o rychlost, musel bych sám hledat.

Pokud by nám šlo přímo o web server, tak mám zafixovaný ngnix jako nejlepší variatnu.

Editováno 3.1.2017 12:24

Nahoru Odpovědět

3.1.2017 12:24

"I disapprove of what you say, but I will defend to the death your right to say it" - Evelyn Beatrice Hall

Marian Benčat

Člen

Marian Benčat:3.1.2017 12:32

Vesměs souhlas. Jen.. i to PHP7 je pořád děsně pomalé, pro obyčejný web ale stačí, horší je to s jazykem (viz. tvoje poznámka ).

Co se týče bezpečnosti, myslím si, že na tom bude Javascript stejně, né-li hůře, problémem je NPM a verzování, konkrétně jde o to, že téměř každý balíček je závislá na pár balíčcích co mají přímo v sobe různé vážné bezpečnostní problémy - sice na to samotné NPM často upozorní, ale uživatelé to často ignorují, jelikož je to jen warning a warningu je tam vždycky 1000.

Osobně bych Javascript nedoporučil, ale respektuji, že se někomu na serveru líbí.

Co se týče rychlosti ASP .NET a Javy:

. Ale co jde o rychlost, musel bych sám hledat.

Jak Netty, tak .NET Core je ještě mnohem propustnější než Node.JS (který je často volen kvůli propustnosti), rychlostí jsou samozřejmě také mnohem dále, ale většinou ti jde o tu propustnost.

Myslím že RoR je asi na ústupu a jeho kousek z dortu si pro sebe stáhnul Python, ale ruku do ohně bych za to nedal..

Nahoru Odpovědět

3.1.2017 12:32

Totalitní admini..

Jiří Fencl

Člen

Jiří Fencl:3.1.2017 12:49

Tak to by me docela zajimalo, jak je php7 pomalejsi nez php5. Mam kvalitne napsanou aplikaci, ktera na php5 potrebovala 6jader a ted jede v pohode na 4jadrech pri 20% narustu trafficu... Spis to tipuju na spatny kod neb sedmicka je docela narocna na kvalitu

Editováno 3.1.2017 12:50

Nahoru Odpovědět

3.1.2017 12:49

Marian Benčat

Člen

Marian Benčat:3.1.2017 12:51

Nikdo nerekl ze PHP7 je pomalejsi nez PHP5. Já jen říkám, že pořád je PHP7 třeba 50-200x pomalejší, než konkurence.

Nahoru Odpovědět

3.1.2017 12:51

Totalitní admini..

Neaktivní uživatel

Člen

Neaktivní uživatel:3.1.2017 13:28

V html a css se dá vytvořit statická prezentace. Nevýhodou je nutnost při každé změně obsahu sahat do kódu.
Co se týká drobných prvků jako je odeslání emailů ze stránky, to se dá řešit i bez vlastního backendu.

Co se backendu týká, tak samozřejmě má vliv na odezvu. Nicméně k tomu flamu tady o tom, který programovací jazyk "ho má většího" bych chtěl dodat, že volba programovacího jazyku a backendu je spíš otázkou daného konkrétního projektu.
Jsou jazyky které mají větší vlastní režii, pomalejší interpreter a podobně, ale u malé aplikace to nebude mít v podstatě žádný dopad protože výkon prostě dotlačí hardware. Naopak jsou projekty kde se počítá s obrovskou zátěží a vlastní režie musí být co nejmenší jinak by výkon serveru nestačil a pak je potřeba volit i vhodný jazyk a backend.

Jinak k těm rychlostem, porovnání je těžké a syntetické testy o ničem zásadním nevypovídají. V jednoduchých matematických operacích, práci s poli může php 7 být dvakrát rychleší než java 8 a podobně, ale jak říkám, to neznamená že jeden nebo druhý jazyk je horší nebo lepší, každý má to svoje pozitivuma negativum.

https://blog.famzah.net/…ark-2016-q3/

Nahoru Odpovědět

3.1.2017 13:28

Neaktivní uživatelský účet

Marian Benčat

Člen

Marian Benčat:3.1.2017 13:55

protože výkon prostě dotlačí hardware.

Todle je právě bohužel nepravda. Už z toho co jsi napsal vím, že tomu rozumíš, takže jistě víš, že největší dopad na execution time v dnešní době "nařachaných" CPU není to, že by to brzdilo CPU, ale I/O a teď nemluvím o databázi, ale opravdu o rychlejším úložiště - Cache a RAM.

Todle je věc, který "hardware nedotlačí" a proto je problém to, jak to s PHP je a pokud se od základu nepřekope, tak ani není možné aby bylo rychlejší. Proto mohu říct, že pokud by byla někdy pravda todleto:

V jednoduchých matematických operacích, práci s poli může php 7 být dvakrát rychleší než java 8

Tsk přísahám, že sežeru svoji botu, protože to by musel být hodně zmanipulovaný test, aby pole implementované jako Hashtable s nesekvenčním linked listem (PHP7) bylo rychlejší než klasické pole.

Dostáváme se tedy do omezení ne výpočetního výkonu, ale I/O přístupu a tam ti žádné rychlejší CPU, nebo rychlejší paměti moc nepomohou. Prostě vždy bude rychlejší, když projíždíš standardní pole, kde máš prvky za sebou a dostaneš je do řádky cache, než skákat s každým prvkem po heapu.

Ještě bych chtěl říci, že toto ani nebyl žádný flame war,.. ani neměl být. Stanislav se zeptal mj. na rychlost odezvy, zda je závislá na backendu (PHP/JS) a tak jsem mu odpověděl.

Nebyla to taky jediná část moji původní odpovědi.

Nahoru Odpovědět

3.1.2017 13:55

Totalitní admini..

Neaktivní uživatel

Tvůrce

Neaktivní uživatel:3.1.2017 18:00

PHP ako také nebolo vždy rýchly jazyk, ale s PHP 7 sa toho dosť zmenilo. Dosť. Už istotne nie je najpomalšie. Prednedávnom som našiel toto porovnanie: https://blog.famzah.net/…chmark-2016/. Ako každý iný test to tiež nie je 100% objektívne, samozrejme v reále závisí rýchlosť od veľa iných vecí, ale orientačne, si myslím, že to môže byť.

Nahoru Odpovědět

3.1.2017 18:00

Neaktivní uživatelský účet

Marian Benčat

Člen

Marian Benčat:3.1.2017 18:25

Mno. Type erasure u javy je velký problém a tak jak to je napsane pomocí arraylistu to asi nikdo nenapíše, kdo o boxingu ví. Ale souhlasím, že se vždy dá napsat test tak, aby něco bylo pomalé. Python je většinou pro lidi největší překvapení.. Nebo spíše zhrozeni.

Nahoru Odpovědět

3.1.2017 18:25

Totalitní admini..

Neaktivní uživatel

Člen

Neaktivní uživatel:4.1.2017 8:30

Napsal sem to blbě a vyznělo to asi jinak než sem to myslel. Pojmem "malá aplikace" sem měl namysli právě aplikace nenáročné na I/O.

Co se rychlosti php týká, tam není asi důvod nějak diskutovat. Máš pravdu, že v praxi je php pomalejší než jiné jazyky (java, c++).
Tím, že může být rychlejší než java sem poukazoval na to, že syntetické testy se dají napsat tak jak se testerovi zachce, aby to vyšlo. Odkaz co jsem dával je ten samý jako od Neaktivní uživatel a sám vidíš že je tam java pomalejší, ale oba víme, že je to proto, že je ten test zle napsaný. Koneckonců sám tester když "zoptimalizoval" kód testu pro javu tak uznal, že je mnohem rychlejší než php.

Nahoru Odpovědět

4.1.2017 8:30

Neaktivní uživatelský účet