Vlákno názorů ke článku Dependency Injection ještě jednou :-) od RS - Podival jste se opravdu jak ty DI kontejnery...
-
Podival jste se opravdu jak ty DI kontejnery v Nette / Symfony funguji pod poklickou? Protoze oni ty yamly / nenony se parsuji prave jen jednou vznikne z nich stare dobre PHP ktere je jeste navic plne optimalizaci takze se instance vytvari az kdyz jsou skutecne potreba a ne do zasoby coz se rozhodne neda rict o
Product::setDb(new Db())ktere pravdepdobne skutecne musite vykonat s kazdym requestem prestoze se zrovna Product nepouzije
Kdyz to prezenu tak vysledkem toho DI v nette / symfony je obycejne pole kde klicem je Jmeno Servisy a hodnotou pak tovarna. Tento soubor se drzi v opcache takze ziskani servisy je bleskovka dokonce si tvrdim rict ze to bude rychlejsi nez vami popisovany reseni. Jedine co by se dalopovazovat za problem je pamet praxe ukazuje ze i ve velkych projektech se jedna o stovky Kb max nizsi jednotky Mb (ktere jsou navic v novem PHP sdilene prave v opcache takze to ani neni per request).
Tim padem argument performance opravdu odpada.. k dalsim pozdeji :)
-
Snad všechny frameworky vyžadujou write permissions na nějaký "var" nebo "cache" adresář. Potřebujou uložit zkompilované templaty, konfigurace a všechny tyhle další věci (díky tomu, že PHP prostě funguje od základu blbě). Samozřejmě pokud není server nastavený úplně kravsky, tak to nijak neovlivní nemožnost zapisovat kamkoliv jinam. Nebo jak mi jeden adresář vlastněný uživatelem www-data ovlivní zranitelnost zbytku systému?
-
Njn, to potrebuje kazda aplikacia, len tie rozumne vytvorene alplikacie to pouzivaju ako variable alebo cache, nikdy tam nemaju nastavene prava vykonat kod a spravidla v cache nema byt nic co nejakym sposobom zmeni chovanie systemu.
To nie je tym ze by PHP fungovalo blbo, aj s PHP sa da pisat bezpecny kod. Blbo od zakladu fungovalo smarty a dalsie frameworky ktore idu v jeho odkaze.
-
Nepsal jsem nic o bezpečnosti kódu v PHP. A prostě funguje blbě už ze svojí podstaty - v normálním jazyce by se ta šablona zkompilovala jednou a výsledek by se držel v paměti. Ale protože PHP má model "shared-nothing" mezi requesty, musí se zkompilovaná šablona někam uložit. A protože je potřeba, aby to bylo relativně efektivní (protože zase, bude se načítat při každým requestu), tak se musí uložit jako spustitelný PHP kód.
-
Tak aj v pripade PHP je mozne tu sablonu skompilovat raz a drzat ju v pamati opcache, to je potrebne ale urobit uz pri deploy (napr, v ramci CI). Kedze sa ta sablona zmeni az pri dalsom deploy, tak kompilovat ju az na servri a pouzit vlastnu cache nema zmysel, hlavne ked to do kodu zavadza bezpecnostnu dieru.
PHP nie je shared nothing, mate moznost pouzit shared mem, tu je nutne pouzit aj v inych jazykoch, ak aplikacia bezi vo viacerych vlaknach. Njn, kto so shared memory nevie, moze pouzit adresar na disku...
-
Ty by ses měl někdy podívat i mimo hranice PHP, abys zjistil, jak fungujou normální jazyky.
Jestli kompilaci dělat při deployi nebo just-in-time při prvním requestu je celkem jedno, a žádnou bezpečnostní díru to nezavádí, to už jsme řešili jinde.
Ano, v PHP se dá použít opcache. A právě proto se všechno musí předkompilovat do PHP skriptů. Protože prostě bez držení věcí v paměti se výkon získat nedá a nic jinýho než zkompilovanej PHP kód mě PHP v paměti držet nenechá. Vracíme se pořád k tomu samýmu. PHP je špatně už z principu, jen ty nic jinýho nejspíš neznáš, tak to pořád nechápeš.
To o těch "jiných jazycích" a více vláknech nemá smysl komentovat - zkus se podívat třeba na Javu/C#/Erlang/Rust/Go, jak může vypadat příčetný vícevláknový program, který nemusí používat žádný hacky typu "shared mem".
-
Pravda, svoje využití má. Ale řekl bych, že spíš na menší weby s nízkým provozem, kde by se věci držet v paměti ani nevyplatilo. Jakmile se začne řešit performance (nebo nedejbože vlastní server), je nejspíš čas přejít na jiný jazyk.
Stejně jako když v bash skriptu je potřeba vytvořit funkci, tak to většinou znamená, že je čas ho přepsat třeba do Pythonu.
-
Malokdy je suktecny performance problem v PHP nechcu ho tady obhajovat sam preferuji jine jazyky ale pravda je ze pro PHP je mrte hostingu. Tim ze se vzdava multi-threadingu tak je mnohem pristupnejsi pro zacatecniky. Vetsina web-requestu multi threading skutecne nevyuzije..
Ale zpet k performance prvni facebook (pravda tam se od PHP uteklo ale i ta verze co v PHP byla napsana tak byla rozsahem rozhodne VELKY) , wikipedie nemyslim si ze jsou to male projekty a performance zvladaji.. ono kdyz si vezmete prumernou webovou aplikaci tak samotny HTTP request je relativne pomala zalezitost, pak tam mate vetsinou naky dotaz do DB to je taky docela dost pomale (at je ten dotaz sebe rychlejsi tak je tam sitovy roundtrip) a to co je mezitim na celkove performance zase tolik neprida.. Samozrejme pokud lovime kazdou ms tak je PHP mimo ale na vetsinu beznych veci to opravdu staci.. A on i ten typovy system tam pomalu zacinaji dopatlavat... osobne za dve nejvetsi chyby jazyka povazuju
1) Naprosto chaotickou standardni knihovnu..
2) datovy typ Array ktery je v PHP kombinaci Mapy, Setu, Listu ... to je takovy paskvil ze se z toho chce brecet. -
Humanoid č. 1264054 - poruchovýBronzový podporovatel
Chtěl jste napsat "do Rustu" a spletl jste se, chápu;-)
-
Su firmy kde je nastavena urcita politika zabezpecenia a cez tu vlak nejde, iste videl som servre kde je selinux default vypnuty, a vsade mozne pouzity chmod a+w... To ako ste sa niekde v diskusii vyjadril ze ste ten co vsetky weby dava do late, tak by ste sa mohol podelit ako dokopat security team aby vam dal write prava na cely adresar aplikacie VZDY...
