Generally, yes. For large applications, having them load all their dependencies on every run is wildly inefficient. For tiny little apps that don’t load a bunch of extra junk, it may be fine. e.g. if you just need to serve out one tiny API endpoint and you can write a Perl/Python/Ruby/PHP script that runs in a few milliseconds, then it may make sense to use CGI (but an app server probably isn’t notably worse than CGI in those cases, either…it’d be about balancing CPU vs. memory usage).
No. FastCGI can not run CGI scripts. It requires applications built to communicate via the FastCGI protocol, which is not the CGI protocol. A CGI script is not a FastCGI script without a wrapper. We provide a wrapper (fcgiwrap), so you can run CGI applications on systems that don’t have suexec available, but it does not mean FastCGI is running CGI scripts. fcgiwrap runs CGI scripts and communicates with the web server via the FastCGI protocol. It is the application server in this context.
We didn’t install php-cgi. That’s your business, not mine. (Though it might be a dependency of one of the other PHP packages we install…I don’t think so, though. I can’t think of any reason any of the other PHP packages would depend on php-cgi.)
Actually, it probably is a dependency of one of the other PHP packages, as we’ve never installed it, and we’ve historically had the ability to run PHP apps as CGI, so I guess it must have always been there.
Yeah, but you almost certainly don’t need that. I only ever use FPM. Sometimes I like to have CGI for debugging other execution modes, but it’s not how you should ever run a large PHP application.
I mean, Virtualmin detects available execution modes when the config check runs. So, it won’t offer that option if you don’t have php-cgi and that’s a harmless thing.
one of the things I really love about the php-fpm framework is you can control the max child processes - so a website becoming very busy will NOT spawn hundreds of child processes — perhaps my old system with FastCGI was not configured properly and that was why I did have 100s that then triggered OOM issues. We specifically changed over to php-fpm to have better control over excessive processes that used to lead to OOM issues.
But, this is a bit misleading: “Virtualmin only supports CGI apps out of the box. You can manually add FastcGI support.”
Virtualmin supports, with full UI support, PHP apps via many execution modes, including FastCGI, and multiple versions of PHP (when installed). Virtualmin also supports setting up proxy rules to any other kind of application server (many app servers do not use FastCGI, they just use HTTP, and that is the most common way to run most apps other than PHP at this point in history). FastCGI is on the way out, too.
We brought proxy paths support from Pro into GPL just recently to ease that use case. And Virtualmin Pro is about to get app server and container-based app support (where it has some awareness of the app server or docker/podman and configures the proxy rules automatically).
So, nearly any way you want to run apps in Virtualmin is very easy to do.
and didnt really know.
