Vlákno názorů k článku HTTP/3: co nám nový protokol přinese a proč to hned tak nebude od anonym - QUIC se mi libi; protoze uz i ted...
-
Kuriozita je spíš to, že stále existuje mpm_prefork a mod_php.
Mpm_prefork je není ani tak pre-fork, jako spíš pre-historie. Je s podivem, že ho Apache vůbec ještě zachovává. Podle mě popularita Apache upadá právě i díky tomu, že udržuje morálně zastaralé technologie. Nginx získává popularitu právě proto, že razí jednu "best practice" cestu a nedovoluje, aby to admin vyprasil.
Je mnoho důvodů, proč používat mpm_worker + php_fpm a není prakticky žádný důvod pro používání mpm_prefork + mod_php.
-
Prave ja jsem nikdy s Apache a preforkem (az na to h2) problem nemel, zatimco z FCGI PHP ano.
Apache mimo jine i diky tomu, ze existuje dlouho ma k dispozici hromadu modulu, ktere dokazou mnoho, zatimco nginx mimo jine i kvuli sve jednoduchosti nejake moduly strada.
FPM spolecne s nginx jsem zkousel, a stale teda nechapu jak, ale podarilo se mi, ze se php kod spoustel pred uspesnym overenim pres Digest auth, coz byla obrovska bezpecnostni trhlina.
FPM s Apache byl oproti modulu trosku narocnejsi, coz by pro RPi Zero mohlo pri vyssi navstevnosti (nebo utoku) cinit problemy.
Ale abych pouze nekrivdil, tak Nginx se vyborne osvedcil jako reverzni proxy :) -
Právě většina těch Apache modulů je toxických, jsou to ohejbáky, mnohdy velmi obsoletní (např. peklo jménem "htaccess"). FPM funguje spolehlivě i s Apache / mpm_worker. Naopak forkování je náročnější operace, mělo by to být méně výkonné, než worker. Jediné, co mě napadá je, jestli jste neměl nastavený FPM na pm.dynamic, nebo neměl příliš velký static pool.
Nginx opravdu nemusí vždy stačit, ale Apache bych určitě přepnul do mpm_worker + PHP FPM.
-
na tradiční multihostingu je apache s mpm_prefork a mod_php nutnost.
když na jednom serveru máte pár tisíc hostingů, které mají jdenotky návštěv denně, tak je nesmysl aby pro každý hosting běžel samostatný worker, minimálně kvůli paměti.
a přechod napříkad na nginx je naprosto nemožný. není možné zákazníkům sebrat htaccess. nginx žádnou podobnou variantu nenabízí, takže by bylo nutné editovat přího konfiguraci vhostu a vstup od zákazníka by se musel složitě parsovat, jestli se náhodou nesnaží o něco, k čemu nemá přístup.
-
Pro každý hosting nemusí běžet nezávislý worker, vůbec ne. Princip je prakticky stejný, jak o u preforku, jen nedochází právě k náročné operaci fork(). Nevýhodou preforku je i to, že každý fork musí nutně natahovat i mod_php a tedy žere paměť. U worker naopak obslouží statické soubory a jen na volání PHP zavolá FPM. FPM pak požadavky agreguje, takže je potřeba daleko méně paměti, než u preforku.
Tj. s výkonem je to přesně naopak, než píšete. Mrkněte např. na PLESK panel, kde je běžné obsluhovat tisíce webů, je tam reverzní nginx pro statické soubory (+ možnost editovat konfiguraci uživatele) + možnost apache (ale není nutné ji využívat). PHP je řešení přes FPM, mod_php je nedoporučován. (Zde: https://support.plesk.com/hc/en-us/articles/213371169-High-CPU-and-memory-usage-by-website)
Htaccess je výkonnostní past. V 99 % případů slouží k přesměrování požadavku do nějakého frameworku - tj. POKUD EXISTUJE statický soubor POTOM servírujeme statický soubor. ELSE předáváme vše do index.php.
Ostatní direktivy v htaccess jsou různé ohejbáky na zastaralé systémy. Např. zamezení autoindexu (které je dnes už ale standardem), řešení kódování (které už opět řeší spolehlivě aplikace), zákaz přístupu do adresáře (což se stejně má řešit tím, že je mimo document root) atd. Když se nad tím vším zamyslíte, zjistíte, že ve skutečnosti htaccess není potřeba, ale že se jedná jen o dlouholetý (a špatný) zvyk.
