Best practices for running Perl?


#1

Hello,

My apologies for the newbie question; I have poked around quite a bit
and can’t find a definitive answer.

I’m planning to use nginx to set up a lightweight server on a slim
virtual-slice host where resources are at a premium. The server will
mainly just relay data from clients to back-end systems, so I don’t
need a fancy render layer or persistence model. I’m planning to go
with Perl for its stability and light footprint.

My question is, what is the current best-practice for running Perl
behind nginx? Is the built-in Perl module stable enough to consider
using in production or should I stick with a hand-rolled FCGI wrapper?

If someone feels that there would be a better slim-language choice
that is better supported by nginx instead of Perl, I would appreciate
hearing about that as an alternative.

Cheers,

Mark


#2

IMHO starting with Perl… and nginx… you are putting a dinosaur in
a cage with a racecar. maybe at least PHP, or, depending on the
project, some people like Ruby or Python…


#3

in reading more closely, scratch Ruby… but I still would consider PHP
before Perl…


#4

I use Rails heavily for sites that need a full render and persistence
layer, but even Ruby alone is unnecessarily heavy for such a simple
server.

I would personally prefer Perl to PHP but would run PHP if there is a
good production-ready way to deploy it behind nginx but not Perl. Is
that the case?

Mark

On Thu, Apr 30, 2009 at 11:54 AM, Chris Cortese


#5

I would consider php more lightweight than perl in general, even
though perl is a good option for various logfile and other
text-processing related tasks

On Thu, Apr 30, 2009 at 11:54 AM, Chris Cortese


#6

Let me ask a more focused question, since we don’t really need to use
the nginx list to debate web languages.

1 - Is the nginx built-in Perl module ready for production use? Has
anyone here used it in a production environment?
2 - If not, what is the current best practice for running Perl behind
nginx in production?
3 - What is the current best practice for running PHP behind nginx in
production? Is this better than the answer for Perl?

Thanks!

Mark


#7

If it has to be perl, I’d say look into using fcgiwrap.

Otherwise, use PHP. It’s slim enough and very easy to deploy and proxy
to using nginx.


#8

Hello!

On Thu, Apr 30, 2009 at 11:46:47AM -0700, Mark Aiken wrote:

My question is, what is the current best-practice for running Perl
behind nginx? Is the built-in Perl module stable enough to consider
using in production or should I stick with a hand-rolled FCGI wrapper?

Embedded perl in nginx is NOT for general purpose programming. It
runs in nginx worker processes and it MUST NOT block (or all your
connections in the same nginx worker will be blocked as well) -
and this generally means you can’t use DBI, anything that resolves
hostnames and so on.

It was designed to do small things that can’t be easily done with
nginx itself - e.g. map some variable to another complex one -
and it does this well enough. But don’t try to use it for general
purpose web programming.

Use either fastcgi or http backends if you need something general.

Maxim D.


#9

Embedded perl in nginx is NOT for general purpose programming. It
runs in nginx worker processes and it MUST NOT block

Ah, this is very important to know! Thank you, Maxim!

Mark


#10

from the docs on the built in module, it seems to run inline with
nginx, so, any large or blocking operations would be a very bad idea.
they say that the module is highly experimental and that bugs are
likely, as well as nginx supposedly will “laugh at your code and hit
on your girlfriend”. Basically, you shouldn’t run a typical program
inside the module, maybe a small snippet of code, but nothing that
does very much. I think it’s designed so you can easily write plugins
to modify nginx behaviour, rather than as a replacement for a cgi or
fastcgi situation.


#11

If you are truly committed to running Perl…

your best option would be this:

Port 80 : Nginx serves static and proxies to Perl system
Port 80xx : Perl system ; either apache+fcgi or apache+mod_perl …
you might be able to run things under perlbal via plugins, but i dunno.

The ideal situation would be running fcgi under nginx, but I found it
a PITA to set up / maintain.

I caved in and ran some perl apps through apache+mod_fcgi , and its
pretty nice. Nginx handles most of the requests itself, so 2 apache
children are handling a decent amount of traffic.

I have a few production projects running nginx on 80 and proxying back
to mod_perl enabled apache. They work great, but they’re apps
designed to utilize a bunch of MP + Apache2 features… nginx was
brought in a few years ago to increase improvement… and it was
miraculous: nginx does awesome queuing/handoff of the mp traffic, so
all apache does is process mod_perl fast and instantly. no lazy
client issues, no wasting resources on bloated servers.

in practice… i haven’t found /that/ much difference between a fine-
tuned Apache+ModPerl , PHP ( via apache+mod_php or fcgi ) , Python
( django / pylons ) setup. Sure you can have a system where php+fcgi
is taking up 50MB of ram while Apache+ModPerl is taking up 150… but
to tweak the performance to equal one another you’d use a PHP cache
that takes up 135MB of ram… making everything pretty darn negligble.


#12

There exist a few options to handle Perl CGI and such… I removed all
traces of Apache from 3 machines…

fcgiwrap


#13

Mark Aiken Wrote:

Let me ask a more focused question, since we don’t
really need to use
the nginx list to debate web languages.

1 - Is the nginx built-in Perl module ready for
production use? Has
anyone here used it in a production environment?

From http://wiki.nginx.org/NginxEmbeddedPerlModule:

Known Problems

This module is experimental; therefore anything is possible and bugs are
likely.

  1. It’s possible for Nginx to leak memory if you reload the
    configuration file (via 'kill -HUP ').
  2. If a Perl module performs protracted operation, (for example DNS
    lookups, database queries, etc), then the process that is running the
    Perl script is completely tied up for the duration of script. Therefore
    embedded Perl scripts should be extremely careful to limit themselves to
    short, predictable operations.
  3. Nginx may laugh at your Perl code and hit on your girlfriend.

2 - If not, what is the current best practice for
running Perl behind
nginx in production?

I would use fcgiwrap which seems to work well in most situations. See
http://nginx.localdomain.pl/wiki/FcgiWrap.

3 - What is the current best practice for running
PHP behind nginx in
production? Is this better than the answer for
Perl?

That’s a question of religion. Some people insist on proxy to Apache
with mod_php. Others prefer fastcgi using fastcgi_pass directive.

How you start php-cgi is also a matter of religion. Some use spawn-fcgi,
some use php-fpm, some use the nifty init script at
http://wiki.nginx.org/RedHatPHPFCGIInitScript.

I use fastcgi and php-fpm. See http://php-fpm.anight.org/download.html.
There is a patch for php 5.2.9 at
http://www.2shared.com/file/5008466/4549200/php-fpm.html.

Better than Perl? Depends what you are doing with it I suppose. From the
little that you describe I would likely prefer php.

and other

IMHO starting with Perl…
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,1586,1593#msg-1593


#14

Michael S. wrote:

If it has to be perl, I’d say look into using fcgiwrap.

You will get performance like CGI (new process started on every
request). I would not say it is THE best practice.

Otherwise, use PHP. It’s slim enough and very easy to deploy and proxy
to using nginx.

My personal experience is that perl fcgi processes could serve an order
of magnitude more requests per second compared to the same functionality
php fcgi process with roughly the same memory consumption. In the both
cases the test was CPU bound.

Best regards
Luben Karavelov


#15

Mark Aiken wrote:

Let me ask a more focused question, since we don’t really need to use
the nginx list to debate web languages.

1 - Is the nginx built-in Perl module ready for production use? Has
anyone here used it in a production environment?
2 - If not, what is the current best practice for running Perl behind
nginx in production?

Му experience is running FCGI processes behind nginx. You should make an
init script to run them (look for FCGI-ProcManager) or you could use
“spawn-fcgi” from lighttpd distribution or cgi-fcgi distributed with
libfcgi. You should start the scripts independently of the http server.

3 - What is the current best practice for running PHP behind nginx in
production? Is this better than the answer for Perl?

fcgi processes

Thanks!

Mark

If you are using CGI::Application as a framework, send me a mail
off-list to share some experience.

Best regards
Luben Karavelov


#16

I am coming from the camp where I cannot alter the application. Coding
one from scratch sure you can impelement an fcgi interface.


#17

This will work seamlessly with bugzilla?

Also we have a strict policy with not modifying the source package for
easy upgrades. I’m sure somehow you could hack this kind of support
into bugzilla but that would be a lot of modification.


#18

Michael S. wrote:

I am coming from the camp where I cannot alter the application. Coding
one from scratch sure you can impelement an fcgi interface.

It is already implemented. it is as simple as:

use CGI::Fast;
use FCGI::ProcManager qw(pm_manage);
pm_manage( n_processes => 10 );
while (my $cgi = CGI::Fast->new()) {

}

Best regards
Luben


#19

Michael S. wrote:

This will work seamlessly with bugzilla?

Also we have a strict policy with not modifying the source package for
easy upgrades. I’m sure somehow you could hack this kind of support into
bugzilla but that would be a lot of modification.

I have not running installation of bugzilla but in the docs it says it
could run under mod_perl. There is also a configuration file included in
the application for mod_perl, that could be tweaked. So I think it will
be easy but not trivial task to run it as fast-cgi without source
modification.

Best regards
Luben


#20

Michael S. wrote:

This will work seamlessly with bugzilla?

Also we have a strict policy with not modifying the source package for
easy upgrades. I’m sure somehow you could hack this kind of support into
bugzilla but that would be a lot of modification.

ОК,
It seams someone have already done it. Look for an example here:

http://cpansearch.perl.org/src/VERESC/FCGI-Spawn-0.1/Spawn.pm

I hope it helps

Luben