Vlákno názorů k článku PHP 8: trojnásobný výkon díky JIT a užitečné novinky pro programátory od Daniel Kozák - Tak ten nadpis je trochu prehnanej. Ve vetsine...

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.

Provoz databáze na hostingu je další dimenze chaosu. Ty projekty, které si vybavuji, byly pomalé sami o sobě. Sdílení čehokoliv (disky, virtualizace, cloud) do toho ještě přidává další faktor.

@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.

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í.

To je ještě relativně dobré. V dnešní době frontendových frameworků se potkávám stále častěji se stavem, kdy se surová data pošlou na klienta a všechno motání probíhá tam. A to je teprve paráda.

@87vdf4vg82

Hromadné jevy lze hodnotit z odstupu zjednodušeně a nijak to nenarušuje integritu jedince. Právě i z těch důvodů, co jste vypsal.

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).

Ono to chce, aby SQL datový model navrhoval někdo, kdo to trochu umí.

Mimochodem, co používáte za databázi, že tam zápis blokuje komplet čtení? Sqlite?