Ono to může být zajímavé. Je "tradiční" programátorskou prasárnou v PHP dělat scripty, co běží sekundy, desítky sekund i minuty. To způsobuje spoustu problémů, instancí PHP není na serveru nevyčerpatelně. Programátory nezměníte (aspoň ne rychle), takže pokud tomu trochu pomůže urychlení PHP, tak jen dobře - jakkoliv je to narovnávák na ohejbák.
Každý, kdo si zkoušel dělat nějaké úlohy třeba pro Project Euler, brzy zjistí, že vejít se do časového limitu výpočtu není věcí zvoleného programovacího jazyka, ale vhodně napsaného algoritmu. Jinými slovy, pokud je programátor nezkušený a/nebo neví co dělá, optimalizace interpreteru je slabá náplast.
2. 12. 2020, 10:59 editováno autorem komentáře
Jinými slovy, pokud je programátor nezkušený a/nebo neví co dělá, optimalizace interpreteru je slabá náplast.
Pokud by programátor věděl co dělá, nikdy by PHP na webu nepoužil. To, že se musí celé prostředí s každým scriptem od nuly sestavit a počet procesorů není nevyčerpatelný, by PHP dopředu odsuzovalo k neživotu. Ale jak vidíme, tak žije, a s (nemalými) problémy funguje ke spokojenosti.
Každá náplast je pak dobrá. JIT, preloading tříd, ... Můžeme tu hodiny filozofovat nad tím, že existuje spousta vhodnějších technologií, ale tím programátory nezměníme. Ti si budou dál bastlit své PHP scripty, data zpracovávat ve smyčkách programu místo znalosti SQL, a nad to budou lepit zázračné cache mechanismy, preloading a JIT. Toť realita.
Miroslave, ono je docela často o dost snažší pročíst pár-řádkovy foreach než dešifrovat co autor myslel tím překomplikovaným SQL.
Ano, dělá se to z lenosti a neznalosti SQL, to chápu. SQL příkaz není o nic méně čitelný, navíc dáte stroji možnost práci s daty značně zoptimalizovat. Což už se pak špatně dohání v interpretovaném jazyce - JIT tomu může maximálně trochu pomoct.
To vůbec nesouvisí s interpretovaným jazykem. Pokud datové schéma nenavrhoval nějaký matlal, jsou data v databázi uložena tak, aby se dala rychle získat. Tj. nepotřebná data se pokud možno vůbec nenačítají z disku, případně nějaká menší část zbytečných dat se alespoň neodesílá po síti. Když data budete zbytečně načítat z disku, nezachrání to pak ani kdybyste je filtroval programem napsaným přímo ve strojovém kódu.
Prerekvizitou takového stavu ale je, aby databázové schéma a všechny query dělal databázový architekt a ne programátor. To jsou totiž dva dost rozdílné obory.
Ale popravdě - u většiny projektů se dnes nevyplatí investovat čas do větších optimalizací, je jednodušší a levnější použít knihovny co query do databáze vygenerují sami ( ostatně výsledek je často i tak lepší, než když se tu query pokouší napsat někdo, kdo to moc neumí ). Až u opravdu velkých projektů má smysl to optimalizovat víc .... ale to až ve chvíli kdy vynaložené náklady mají nějakou návratnost. HW je v porovnáním s nákladem na vývojáře většinou levnější.
Z druhé strany - je to zvláštní doba. My co pamatujeme jak se na řešilo jak dostat turbo pascal na jednu 360kb disketu a jak naprogramovat aplikaci, aby se i se systémem vešla do 640kb paměti, je z dnešního přístupu dost smutno.
Tohle je diskutabilní. Máte 90% projektů, které nevyrostou, a které budou obsluhovat pár desítek uživatelů. Pak máte ale projekty, které shodou okolností uživatelé začali používat a vyrostly - případně projekty, které mají šílený datový model a při malém počtu uživatelů jsou neskutečně pomalé. Samozřejmě, že obvykle je za tím práce s databází - bohužel v řadě případů výkonnostní problémy nepořešíte žádným dostupným hw a ani jednoduchým sw fixem - protože je to naprosto debilně navržené.
Takhle problémových projektů je minimum, ale jsou - a do jisté míry je to důsledkem toho, že jsou programátoři od technologie odizolováni, a jednak netuší, co dělají, druhak ani nemají šanci, kde se to naučit.
Osobně si nemyslím, že by databáze nebo dotazy nemohl navrhovat programátor - není to nic komplikovaného. Ale vyžaduje to určité základní znalosti a zkušenosti. A už i v lepších firmách jsem viděl takové blbosti, že nechápete.
Problém je, že ve chvíli, kdy zjistíte, že máte vážný problém s výkonem větší aplikace, tak s tím už prakticky nemůžete nic moc dělat. Banality typu chybějící index nepočítám. Je minimum prográmátorů, kteří vůbec dokáží identifikovat, že mají problém a ještě méně, kteří by dokázali zjistit, v čem ten problém mají.
Takhle problémových projektů je minimum, ale jsou - a do jisté míry je to důsledkem toho, že jsou programátoři od technologie odizolováni, a jednak netuší, co dělají, druhak ani nemají šanci, kde se to naučit.
Problémy vznikají ne na projektu jako jednotlivém, ale ve chvíli, kdy se X podobně "neproblematických" projektů provozuje na sdíleném hostingu. Tam pak dochází k výkyvům, kterým se dá předcházet jen kompromisem mezi předimenzováním výkonu a zpomalením ve špičkách.
Mimochodem, dost častý problém i u malých projektů jsou rozhraní pro správu. Na rozdíl od webového frontendu pro uživatele, kde se pracuje buďto s jednotlivými nebo naopak až s agregovanými údaji, v administraci se pracuje se všemi záznamy. Zákazník se pak nestačí divit, proč mu (skoro) nejede web, když někdo administruje, nebo když zrovna běží nějaký "chytře" napsaný cron job.
Obvykle ty problémy přijdou až po chvíli provozu, až když se zvětší datová nálož.
To odizolování programátorů od technologií je podle mě škoda, ale je to tak. Programátorovi se ještě jakž takž vysvětlí locky v databázi, ale opravdu už velmi obtížně se vysvětluje, co to je FPM pool, že není nevyčerpatelný, a proč je potřeba dbát na to, aby úloha trvala maximálně jednotky sekund (v nejhorším), nebo jinak že je potřeba ji oddělit do jiného poolu a trochu se zamyslet na DB operacemi.
Pokud se bavíme o PHP, není to samozřejmě stoprocentní pravidlo, ale celkové know-how, které se šíří internetem, i způsob, jakým jsou leadovány nejznámější frameworky, vedou právě do těchto pastí. Druhotná potíž je i v tom, že když už problém identifikujete a navrhnete řešení, tak mnohdy zjistíte, že by se celá aplikace musela překopat a spoustu frameworkové magie, na kterou se spoléhá, přepsat úplně jinak.
@Miroslav Šilhavý
Takže podle Vás třeba tvůrci Symfony nebo i samotného PHP či např. D. Grudl neví co dělají?
Viděl jsem spoustu zmatlanin i ve slavné Javě, lepení skryptů je časté táma i supr čupr ultimátním mega Pythonu. Dále si asi neuvědomujete, že programátoři ve většině případů ani nemají na výběr a "patlají" na termín, protože manažeři házeli hračkama na Zoomu dvě hodiny a rozhodli se, že to co bylo včera předěláno na kolo by nakonec přece jenom mělo do zítřka být soudek.
@87vdf4vg82
Symfony i Nette vědí, co dělají. Jen to naráží ve chvíli, kdy ta aplikace začne pracovat s většími daty, nebo kdy je přístupů hodně. Tam to má pak strop, který se dá oddálit leda ohejbáky.
Dále si asi neuvědomujete, že programátoři ve většině případů ani nemají na výběr a "patlají" na termín, protože manažeři házeli hračkama na Zoomu dvě hodiny a rozhodli se, že to co bylo včera předěláno na kolo by nakonec přece jenom mělo do zítřka být soudek.
Myslím, že i to jsem zažil.
Ale mluvíte, jako byste to nezažil. Nikdo netvrdí, že je PHP nejlepší na všechno out of the box, ale v případě extrémních řešení mají i alternativy své limity a na řadu přichází spíš infrastrukturní řešení.
Symfony i Nette vědí, co dělají.
Aha, takže najednou tady máme developery kteří vědí co dělají, na rozdíl od Vašeho paušalizujícího moudra ....
Aha, takže najednou tady máme developery kteří vědí co dělají, na rozdíl od Vašeho paušalizujícího moudra ....
Ti co tyto frameworky používají, ti mnohdy nevědí, co dělají. Mockrát jsem viděl, že se z databáze vezmou nevyfiltrovaná data, fetchAll se všechna přenesou do PHP a tam se kouzlí ve smyčkách. A když se přijde na to, že data už jsou moc velká, dojde paměť a/nebo iterace trvají moc dlouho, najednou docvakne, že správný SQL dotaz by to vyřešil. Tady by stačila obyčejná erudice programátorů - a ta prostě velmi často chybí.
Stejný důvod, opačný problém: ti co zaslechli něco o SQL tak to najoinujou přes osm tabulek, pokud možno tak aby se pořádně ani nedaly přidat indexy, a celé to použijou pro UPDATE nebo DELETE. Výsledek: celá databáze locknutá než operace běžící minuty doběhne. Skvělé pokud to má zároveň odbavovat (relativně) standardním způsobem uživatele (požadavek na webserver -> několik sql dotazů i při zobrazení úvodní stránky (dashboardu).