Mailing List Archive: Catalyst: Users

Lighttpd and mod_perlite

Index | Next | Previous | View Threaded

kiffin.gish at planet

May 31, 2009, 12:19 PM

Post #1 of 15 (2345 views)
Permalink

Lighttpd and mod_perlite

Just wondering what kind of experience folks in the catalyst community
have had using lighttpd/mod_perlite as replacements for the more widely
accepted apache/mod_perl stack. While apache might be better in being
proven technology and mod_perl being better documented, I'm still
looking for lightweight and scalable options.

--
Kiffin Gish <Kiffin.Gish [at] planet>
Gouda, The Netherlands

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

nigel.metheringham at dev

May 31, 2009, 12:49 PM

Post #2 of 15 (2258 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

m.blackman at fairfx

May 31, 2009, 1:06 PM

Post #3 of 15 (2251 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

On 31 May 2009, at 20:19, Kiffin Gish wrote:

> Just wondering what kind of experience folks in the catalyst community
> have had using lighttpd/mod_perlite as replacements for the more
> widely
> accepted apache/mod_perl stack. While apache might be better in being
> proven technology and mod_perl being better documented, I'm still
> looking for lightweight and scalable options.

I guess I'd wonder kind of lightweight you want, catalyst+perl
isn't a very lightweight solution in and of itself, I'd say, as
a result of all the dependencies Catalyst has.

However, lightppd+fastcgi with the fastcgi catalyst server
is the usual answer for this requirement. For me, the most
appealing characteristic of this arrangment was merely the
complete decoupling of the front and back ends. I didn't
notice a big difference in memory footprint between a mod_perl
apache and the fastcgi catalyst server, so I'm assuming
that the application specific memory usage is more important
than anything mod_perl drags in.

On the other hand, you can get the same decoupling with
a minimal apache binary on the frontend and a modperl-only
apache on the backend, with near zero configuration as I still
prefer the apache URL rewriting syntax to lighttpd and I
find the apache documentation more useful. Doing anything
even a little bit unusual with lighttpd always seems to involve
documentation pages that seem a bit light or incomplete.

- Mark

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Jun 5, 2009, 8:52 AM

Post #4 of 15 (2209 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

* Mark Blackman <m.blackman [at] fairfx> [2009-05-31 22:10]:
> However, lightppd+fastcgi with the fastcgi catalyst server is
> the usual answer for this requirement. For me, the most
> appealing characteristic of this arrangment was merely the
> complete decoupling of the front and back ends.

I like to use ::Engine::HTTP::Prefork coupled with whatever
reverse proxy server strikes one’s fancy (whether it be Squid,
Apache mod_proxy, Varnish, lighttpd, whatever). Additionally
I like to use ::Plugin::Static::Simple, sending proper Expires
headers so that the reverse proxy will keep those cached files
around forever.

That takes decoupling to its logical conclusion: the application
server is standalone and works completely independently from the
internet-facing server. You can fire requests at it like you
would at any webserver. You can use the same engine during
development and in production. There are more advantages, but
I forget.

It’s all very, very nice.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

dbix-class at trout

Jun 8, 2009, 11:57 AM

Post #5 of 15 (2190 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

On Sun, May 31, 2009 at 09:19:32PM +0200, Kiffin Gish wrote:
> Just wondering what kind of experience folks in the catalyst community
> have had using lighttpd/mod_perlite as replacements for the more widely
> accepted apache/mod_perl stack. While apache might be better in being
> proven technology and mod_perl being better documented, I'm still
> looking for lightweight and scalable options.

Shadowcat's clients tend to end up on $webserver + FastCGI or $proxy + Prefork
depending on their requirements.

mod_perl is more 'legacy' than 'accepted' to people using practices from
this century.

--
Matt S Trout Catalyst and DBIx::Class consultancy with a clue
Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/
Shadowcat Systems Limited
mst (@) shadowcat.co.uk http://shadowcat.co.uk/blog/matt-s-trout/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Jun 8, 2009, 2:09 PM

Post #6 of 15 (2184 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

* Matt S Trout <dbix-class [at] trout> [2009-06-08 21:00]:
> Shadowcat's clients tend to end up on $webserver + FastCGI
> or $proxy + Prefork depending on their requirements.

What sort of requirements does FastCGI cover better in your
experience?

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

hdp.perl.catalyst.users at weftsoar

Jun 8, 2009, 2:21 PM

Post #7 of 15 (2195 views)
Permalink

Re: Re: Lighttpd and mod_perlite [In reply to]

On Mon, Jun 08, 2009 at 11:09:24PM +0200, Aristotle Pagaltzis wrote:
> What sort of requirements does FastCGI cover better in your
> experience?

I don't know what Matt has in mind, but doing zero-downtime restarts with
FastCGI over a unix socket is pretty easy because of filesystem semantics.

hdp.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

anexiole at gmail

Jun 8, 2009, 3:21 PM

Post #8 of 15 (2178 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

If you can, please suggest some links for reference.:) thanks

Regards,
Gordon Yeong

2009/6/1 Nigel Metheringham <nigel.metheringham [at] dev>

>
> However, I, and many others, are using lighttpd with fastcgi with great
> success - there are a number of articles on this including a few advent
> calendar ones.
>
> Nigel.

list at bereft

Jun 9, 2009, 1:03 AM

Post #9 of 15 (2165 views)
Permalink

Re: Re: Lighttpd and mod_perlite [In reply to]

Aristotle Pagaltzis wrote:
> I like to use ::Engine::HTTP::Prefork coupled with whatever
> reverse proxy server strikes one’s fancy (whether it be Squid,
> Apache mod_proxy, Varnish, lighttpd, whatever). Additionally
> I like to use ::Plugin::Static::Simple, sending proper Expires
> headers so that the reverse proxy will keep those cached files
> around forever.
>
> That takes decoupling to its logical conclusion: the application
> server is standalone and works completely independently from the
> internet-facing server. You can fire requests at it like you
> would at any webserver. You can use the same engine during
> development and in production. There are more advantages, but
> I forget.
>
> It’s all very, very nice.

I'd like to know more about this.

(It almost sounds to good to be true...)

Brad

--
An affected laugh shows lack of self-respect in a man and lewdness in a woman.
-- Hagakure http://bereft.net/hagakure/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

nigel.metheringham at dev

Jun 9, 2009, 1:08 AM

Post #10 of 15 (2172 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

On 8 Jun 2009, at 23:21, Gordon Yeong wrote:

> If you can, please suggest some links for reference.:) thanks

http://dev.catalyst.perl.org/wiki/deployment

I personally use the daemontools mechanism for managing the fastcgi
processes - which is linked in the Managing FastCGI Processes section.

--
[ Nigel Metheringham Nigel.Metheringham [at] InTechnology ]
[. - Comments in this message are my own and not ITO opinion/policy - ]

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Jun 20, 2009, 6:11 AM

Post #11 of 15 (2003 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

Hi Brad,

* Brad Bowman <list [at] bereft> [2009-06-09 10:05]:
> Aristotle Pagaltzis wrote:
> >I like to use ::Engine::HTTP::Prefork coupled with whatever
> >reverse proxy server strikes one’s fancy (whether it be Squid,
> >Apache mod_proxy, Varnish, lighttpd, whatever). Additionally I
> >like to use ::Plugin::Static::Simple, sending proper Expires
> >headers so that the reverse proxy will keep those cached files
> >around forever.
> >
> >That takes decoupling to its logical conclusion: the
> >application server is standalone and works completely
> >independently from the internet-facing server. You can fire
> >requests at it like you would at any webserver. You can use
> >the same engine during development and in production. There
> >are more advantages, but I forget.
> >
> >It’s all very, very nice.
>
> I'd like to know more about this.
>
> (It almost sounds to good to be true...)

what questions do you have? All I can think to say right now is
look at Catalyst::Engine::HTTP::Prefork and work from there…

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

paulm at paulm

Jun 20, 2009, 12:26 PM

Post #12 of 15 (1995 views)
Permalink

Re: Re: Lighttpd and mod_perlite [In reply to]

On Sat, Jun 20, 2009 at 9:11 AM, Aristotle Pagaltzis<pagaltzis [at] gmx> wrote:
> Hi Brad,
>
> * Brad Bowman <list [at] bereft> [2009-06-09 10:05]:
>> Aristotle Pagaltzis wrote:
>> >I like to use ::Engine::HTTP::Prefork coupled with whatever
>> >reverse proxy server strikes one�s fancy (whether it be Squid,
>> >Apache mod_proxy, Varnish, lighttpd, whatever). Additionally I
>> >like to use ::Plugin::Static::Simple, sending proper Expires
>> >headers so that the reverse proxy will keep those cached files
>> >around forever.
>> >
>> >That takes decoupling to its logical conclusion: the
>> >application server is standalone and works completely
>> >independently from the internet-facing server. You can fire
>> >requests at it like you would at any webserver. You can use
>> >the same engine during development and in production. There
>> >are more advantages, but I forget.
>> >
>> >It�s all very, very nice.
>>
>> I'd like to know more about this.
>>
>> (It almost sounds to good to be true...)
>
> what questions do you have? All I can think to say right now is
> look at Catalyst::Engine::HTTP::Prefork and work from there�

I'm curious if anyone's implemented a zero downtime restart system
(the likes of which FastCGI gives you for free) or if it already
exists somehow. Currently we just ^C and restart, which I guess is a
bit lame.

The restart_graceful and pidfile options would go most of the way, presumably?

Paul

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

onken at houseofdesign

Jun 21, 2009, 7:07 AM

Post #13 of 15 (1997 views)
Permalink

Re: Re: Lighttpd and mod_perlite [In reply to]

>>>
>>
>> what questions do you have? All I can think to say right now is
>> look at Catalyst::Engine::HTTP::Prefork and work from there�
>
> I'm curious if anyone's implemented a zero downtime restart system
> (the likes of which FastCGI gives you for free) or if it already
> exists somehow. Currently we just ^C and restart, which I guess is a
> bit lame.
>
> The restart_graceful and pidfile options would go most of the way,
> presumably?
>
> Paul

I wrote an init.d script for debian based systems which heavily based
on the init script for fastcgi.

Check it out at http://dev.catalystframework.org/wiki/deployment/init-http-prefork
.

Cheers

moritz
_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

pagaltzis at gmx

Jun 21, 2009, 7:40 AM

Post #14 of 15 (1990 views)
Permalink

Re: Lighttpd and mod_perlite [In reply to]

* Moritz Onken <onken [at] houseofdesign> [2009-06-21 16:15]:
> I wrote an init.d script for debian based systems which heavily
> based on the init script for fastcgi.
>
> Check it out at
> http://dev.catalystframework.org/wiki/deployment/init-http-prefork

Hmm, I should post my init script too I guess… since we’re on
RedHat. (No, not by my choice.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

list at bereft

Jun 23, 2009, 11:11 PM

Post #15 of 15 (1935 views)
Permalink

Re: C::E::HTTP::Prefork [was Re: Lighttpd and mod_perlite] [In reply to]

Aristotle Pagaltzis wrote:
> Hi Brad,
>
> * Brad Bowman <list [at] bereft> [2009-06-09 10:05]:
>> Aristotle Pagaltzis wrote:
>>> I like to use ::Engine::HTTP::Prefork coupled with whatever
>>> reverse proxy server strikes one’s fancy (whether it be Squid,
>>> Apache mod_proxy, Varnish, lighttpd, whatever). Additionally I
>>> like to use ::Plugin::Static::Simple, sending proper Expires
>>> headers so that the reverse proxy will keep those cached files
>>> around forever.
>>>
>>> That takes decoupling to its logical conclusion: the
>>> application server is standalone and works completely
>>> independently from the internet-facing server. You can fire
>>> requests at it like you would at any webserver. You can use
>>> the same engine during development and in production. There
>>> are more advantages, but I forget.
>>>
>>> It’s all very, very nice.
>> I'd like to know more about this.
>>
>> (It almost sounds to good to be true...)
>
> what questions do you have? All I can think to say right now is
> look at Catalyst::Engine::HTTP::Prefork and work from there…

Sorry to be so slow on the reply.

I think the combination of "There are more advantages, [which the
margin is too narrow to contain]" and "It's all very, very nice"
got me curious enough to ask. Particularly as I'd been running
with the assumption that the various pure Perl servers weren't
production capable (I'm glad to be wrong about this).

Some questions then...
How does it effect administration and server life-cycle?
Can you do any new things, beyond alternatives like Apache/FCGI?
Are there any traps to be wary of?
Do you use multiple CEHP back-ends on a single front-end?

It seems like you could have user-to-backend affinity quite
easily, for a sufficiently small user base.

I should mention that this is the first time I've looked at these
modules, so feel free to send me doc links if the answers are there.

Thanks,

Brad

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads