2

I'm using nginx with this script as FastCGI wrapper, that I start with:

spawn-fcgi -F 3 -u www-data -s /var/run/perl-fcgi.sock -P /var/run/perl-fcgi.pid -- ./perl-fcgi.pl

Now, suppose I have a simple script:

#!/usr/bin/perl

print "Content-type: text/plain\r\n\r\n";
print "hello\n";

The script runs fine, and I see the "hello" when I request /text.pl. But as you can see in line 106 of the FastCGI wrapper, the script gets executed with exec(), so it basically runs in its own Perl environment. Doesn't it ruin the whole concept of FastCGI, when I don't have an already initialized script, but call it independently?

What would be the preferred way of interacting via FastCGI on nginx?

Cheers, --polemon

PS: spawn-fcgi is the program from lighttpd that starts FCGI wrappers and binds them to a socket.

polemon
  • 4,722
  • 3
  • 37
  • 48

1 Answers1

4

Yes, it ruins the whole concept of FCGI, but by design.

The script you're using is an FCGI to CGI adaptor, designed to work around ngnix' deliberate inability to serve CGI scripts.

To use FCGI "properly," just point ngnix at your FCGI-aware script. On the upside, if ngnix can talk to this FCGI-CGI adaptor, you know it can talk to another FCGI script. Specific server configuration is probably a question for serverfault.

pilcrow
  • 56,591
  • 13
  • 94
  • 135
  • The problem is, I'd like to use Perl as any other scripting language with nginx. I have working hooks for Lua and PHP, both run with FastCGI. If I'd run all other Perl scripts as I run the wrapper, I couldn't call any Perl application I like, I'd have to hook every Perl script with its own socket to nginx, which is not preferable. Is there no alternative? – polemon Aug 13 '10 at 05:45
  • @polemon, right. You need an FCGI broker or process manager, one which either spins up your individual scripts as long-running (FCGI) daemons, or which is itself the FCGI interpreter and can, say, dynamically compile stand-alone perl scripts into subroutines which then answer the request. – pilcrow Aug 13 '10 at 20:58
  • @polemon Amongst the problems is that many Perl CGI programs are not designed to run more than once per process. They play fast and loose with global data because its normally thrown away at the end. Putting them into a FCGI loop may cause strange bugs. You can buy yourself some performance without headache by writing a FCGI wrapper that pre-loads common and expensive modules, like Moose, before fork & exec'ing the CGI application. This will save on startup time which is much of the cost of using vanilla CGI. – Schwern Sep 02 '10 at 20:59
  • Have you looked into PSGI/Plack ? – chiggsy Sep 04 '10 at 00:03