Hacker News Reader

Comment by CoolCold | Hacker News Reader

I've tried to do Wordpress benchmark under FrankenPHP and under Apache's Mod-PHP - I couldn't see evidence of winning for FPHP. Have not dug deep enough though and test was in Docker, not on normal setup. Wordpress was basically in default setup - no heavy themes or anything of this sort, not very realistic case too.

Still want to repeat test and understand it better.

View on HN

Unlike Laravel and Symfony, WordPress doesn't support the worker mode of FrankenPHP (yet?), so there are not many benefits in terms of performance (except the ability to preload assets using 103 Early Hints, which can reduce the latency of a page load by 30%).

That being said, FrankenPHP makes it easy to enable HTTP cache with WordPress and simplifies the deployment story. There is a dedicated project for WordPress and FrankenPHP, that comes with a built-in HTTP cache tailored for WordPress (using the Souin Go library): https://github.com/StephenMiracle/frankenwp

> Unlike Laravel and Symfony, WordPress doesn't support the worker mode of FrankenPHP (yet?), so there are not many benefits in terms of performance (except the ability to preload assets using 103 Early Hints, which can reduce the latency of a page load by 30%).

This part is clear for me, but thank you for mentioning HTTP 103 too. I will not state for sure, but in my blurry memory, FPHP (FrankenPHP) was _slower_ than Apache+mod_php in that tests. But again, I won't say for sure, I just remember I was totally impressed as was expecting otherwise - much likely some subtle differences in setup on my side. If/when I have more precise info - I may ping you.

> That being said, FrankenPHP makes it easy to enable HTTP cache with WordPress and simplifies the deployment story. There is a dedicated project for WordPress and FrankenPHP, that comes with a built-in HTTP cache tailored for WordPress (using the Souin Go library): https://github.com/StephenMiracle/frankenwp

Thank you, have not seen that yet - may get idea or two from it. At glance, they just do naive `BYPASS_PATH_PREFIX` handling and that's all.

Beyond tests, I of course do prefer Nginx over Caddy and "simplifies the deployment story" doesn't resonate with my needs much yet - one of that things may change of course.

Maybe you're using that name because you're accustomed to, but as a standard you should be using proxy_fcgi with Apache. Should squeeze out a bit of extra memory out of Apache and leave room for more PHP requests.

Not sure where you take this "standard" from - AFAIR, it was mod_php since ~ 2004-2005 and all that lovely mpm_prefork stuff. FastCGI and FPM came a bit later.

> should be using proxy_fcgi with Apache

I'd in general use Nginx instead of Apache, until .htaccess handling is needed - which is still a thing in shared hosting and around area mostly from my perspective - if you really care about "squeeze out a bit of extra memory" of course.

I take it as a standard because its the approach recommended above all others in the Apache wiki [1] and probably what distros will do at some point as well (RedHat family distros already do this if you don't explicitly opt-in to use mod_php).

[1] https://cwiki.apache.org/confluence/plugins/servlet/mobile?c...

Thank you for clarification - makes a lot of sense what they state in that docs

> Why you shouldn't use mod_php with the prefork mpm anymore

> mod_php is loaded into every httpd process all the time. Even when httpd is serving static/non php content, that memory is in use.

> mod_php is not thread safe and forces you to stick with the prefork mpm (multi process, no threads), which is the slowest possible configuration

I probably very biased here - I silently imply it's a Nginx in front of Apache in 99.9% cases - so serving static files and long-living connections is not a problem with mpm_prefork [for setups and system administration around me].

Reply on news.ycombinator.com