Forum: NGINX Best practices for running Perl?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
61708faeda86d515b04b35d0bec4bf7d?d=identicon&s=25 Mark Aiken (Guest)
on 2009-04-30 20:54
(Received via mailing list)
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
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-04-30 20:57
(Received via mailing list)
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...
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-04-30 21:00
(Received via mailing list)
in reading more closely, scratch Ruby... but I still would consider PHP
before Perl...
61708faeda86d515b04b35d0bec4bf7d?d=identicon&s=25 Mark Aiken (Guest)
on 2009-04-30 21:13
(Received via mailing list)
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
7c1e290bae5edbadcf736921484617ca?d=identicon&s=25 Gabriel Ramuglia (Guest)
on 2009-04-30 21:15
(Received via mailing list)
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
61708faeda86d515b04b35d0bec4bf7d?d=identicon&s=25 Mark Aiken (Guest)
on 2009-04-30 21:46
(Received via mailing list)
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
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-04-30 22:15
(Received via mailing list)
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.
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2009-04-30 22:15
(Received via mailing list)
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 Dounin
61708faeda86d515b04b35d0bec4bf7d?d=identicon&s=25 Mark Aiken (Guest)
on 2009-04-30 22:29
(Received via mailing list)
> 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
7c1e290bae5edbadcf736921484617ca?d=identicon&s=25 Gabriel Ramuglia (Guest)
on 2009-04-30 22:29
(Received via mailing list)
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.
3fc448a0368821b51a9f7e2781a8b7a6?d=identicon&s=25 Jonathan Vanasco (Guest)
on 2009-04-30 22:53
(Received via mailing list)
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.
8072fdc83f765ae5075f252cb4d4d111?d=identicon&s=25 Chris Cortese (Guest)
on 2009-04-30 23:07
(Received via mailing list)
There exist a few options to handle Perl CGI and such...  I removed all
traces of Apache from 3 machines...

fcgiwrap
2974d09ac2541e892966b762aad84943?d=identicon&s=25 Jim Ohlstein (Guest)
on 2009-05-01 15:26
(Received via mailing list)
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
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben karavelov (Guest)
on 2009-05-02 02:43
(Received via mailing list)
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
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben karavelov (Guest)
on 2009-05-02 02:57
(Received via mailing list)
Michael Shadle 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
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-05-02 03:29
(Received via mailing list)
I am coming from the camp where I cannot alter the application. Coding
one from scratch sure you can impelement an fcgi interface.
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben karavelov (Guest)
on 2009-05-02 04:25
(Received via mailing list)
Michael Shadle 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
F5a6ed477b109fe6acc11a5a8f87e7e8?d=identicon&s=25 Michael Shadle (Guest)
on 2009-05-02 06:00
(Received via mailing list)
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.
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben karavelov (Guest)
on 2009-05-02 16:53
(Received via mailing list)
Michael Shadle 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
5447e06c6eeb471861633661aacc3659?d=identicon&s=25 luben karavelov (Guest)
on 2009-05-02 16:56
(Received via mailing list)
Michael Shadle 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...

I hope it helps

Luben
This topic is locked and can not be replied to.