[Catalyst] FastCGI is Weak Sauce

Matt S Trout dbix-class at trout.me.uk
Fri Jun 30 03:00:38 CEST 2006


A. Pagaltzis wrote:
> * Perrin Harkins <perrin at elem.com> [2006-06-29 23:20]:
>> If I'm reading it correctly, he's upset that the protocol
>> between web servers and FastCGI isn't HTTP. He doesn't make a
>> very good case for why, but that seems to be the gist.
> 
> Yes. I take his argument as being that FastCGI has the
> application running in a separate process that can’t be
> communicated with in absence of a webserver because there aren’t
> any utilities that speak FastCGI directly, and if the connection
> between the webserver and the app process isn’t working, you’re
> basically S.O.L. because the app and webserver FCGI components
> don’t give you much information and diagnosing the problem
> without any tools is difficult at best.
> 
> I think that much is just fact.

Sure, but my immediate thought is "so write the tools". Shouldn't be that hard 
to pull apart something like FCGI.pm and build a diagnostics tool from it.

> Basically, what JDD writes makes me think of SQLite. Embedding
> the database engine right into the app makes it tremendously
> easier to deploy and manage. Embedding the HTTP engine right into
> the app should likewise make it a whole lot easier to deploy and
> manage. Sure, writing a solid embedded HTTP engine is no mean
> feat, but writing a solid embedded database engine isn’t either,
> and both have been done.
> 
> It all seems awfully obvious to me; am I wrong?

On my "would be nice to have" list is a POE webserver/static file server/fcgi 
handler that we could bundle to do moderately scalable pure-perl deployment.

And I've happily used the standalone server in forking mode to handle 
lightweight deployment; just because it's usually referred to as the 
"development server" doesn't mean that's all it's good for.

So, Catalyst has both options available, although if you know what you're 
doing a real webserver plus fastcgi will perform better than the standalone 
server ever could.

Other than "we need to write better tools for fastcgi debugging, but I'd 
rather re-invent the wheel instead" I can't see what of this article isn't 
merely stating the obvious - and suggesting things Catalyst already happily 
supports ...

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +



More information about the Catalyst mailing list