Yeah, I remember seeing a whole article about a utility written using PSGI and Perl where the author lamented having to write additional scripts to ensure the services were running. How often was the script run? Once or twice a month I remember -- a use case that should have resulted in CGI being an obvious choice.
The problem with CGI is that it runs a separate process per invocation, but in cases where availability is paramount and low usage requirements exist CGI just makes sense. I am one that believes it never should have been removed from core Perl distributions.
Celebrate Intellectual Diversity
| [reply] |
a utility written using PSGI and Perl where the author lamented having to write additional scripts to ensure the services were running.
Same problem as with almost any setup where webserver and applications run on in different processes. PSGI is perl-specific, FastCGI is not. FastCGI keeps your application running in an isolated process, so crashing the webserver does not kill the application, and crashing the application does not kill the webserver. Getting the application process running is a problem.
You could start it manually. Every time your application crashes.
You could construct something crazy, involving hand-started scripts, cron jobs, and I don't know what else to start the application process.
Or you could make starting your application a problem for the operating system. After all, it is able to start the webserver without manual intervention, so it can do the same to your application. (With daemontools and runit, you simply need a shell script to invoke your application. With systemd, you write an INI-style configuration file to do the same job in a much more complicated way. With a classic init system, you set up a daemon by an init script, or invoke it directly from init. On Windows, you need to set up a service.)
Apache also offers mod_fcgid to manage your FastCGI application process(es) for you, instead of using operating system services. Other webservers might offer similar modules. This has the advantage that you don't need to keep the application process(es) running if there are no requests for them. The disadvantage is that they are not as isolated from the webserver as a process started as an independant daemon started by init, daemontools, runit, or systemd.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
karl@rantanplan:~/src/perl$ pm2 status --no-vizion --no-color
┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐
│ id │ name │ mode │ ↺ │ status │ cpu │ memory │
├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤
│ 1 │ gizmo │ fork │ 0 │ online │ 0% │ 7.9mb │
│ 0 │ mredis │ fork │ 0 │ online │ 0% │ 3.5mb │
└────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘
The process with id 1 is a Perl daemon.
| [reply]
[d/l] |
| [reply] |