[Catalyst] Re: Lighttpd and mod_perlite

[Aristotle Pagaltzis]

* Moritz Onken  [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 // 

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

Re: [Catalyst] Re: Lighttpd and mod_perlite

[Moritz Onken]

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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Lighttpd and mod_perlite

[Paul Makepeace]

On Sat, Jun 20, 2009 at 9:11 AM, Aristotle Pagaltzis wrote:
> Hi Brad,
>
> * Brad Bowman  [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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: Lighttpd and mod_perlite

[Aristotle Pagaltzis]

Hi Brad,

* Brad Bowman  [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 // 

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

Re: [Catalyst] Re: Lighttpd and mod_perlite

[Brad Bowman]

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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Lighttpd and mod_perlite

[Hans Dieter Pearcey]

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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: Lighttpd and mod_perlite

[Aristotle Pagaltzis]

* Matt S 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 // 

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

[Catalyst] Re: Lighttpd and mod_perlite

[Aristotle Pagaltzis]

* Mark Blackman  [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 // 

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