[Catalyst] Slowness on test server caused by reverse DNS lookups

Matt S Trout dbix-class at trout.me.uk
Wed May 31 02:39:25 CEST 2006


Eric K. Olson wrote:
> Hi Folks!
> 
> In writing my first Catalyst Application (and may I say THANK YOU for 
> creating this framework!),
> I noticed a long delay on every request, which I traced to the reverse 
> DNS lookups of the server
> and client IP addresses in Catalyst::Engine::HTTP::_socket_info.  I 
> patched it to have '-nodns'
> and '-noremotedns' to turn off the server and client reverse DNS 
> lookups, respectively.  That patch
> appears below, including a patch to the Helper that generates the 
> myapp_server.pl code.
> 
> I realize that the test server is just for getting people up and running 
> quickly, but I think it
> is important that it have good response time, even in the face of badly 
> configured (or impossible
> to properly configure) reverse DNS records.  I initially attributed the 
> delay to actual processing,
> which made Catalyst look REALLY slow.  It was 100% DNS timeouts-- even 
> with the test server my
> App (using TT and DBIC::Schema) is REALLY fast.
> 
> Questions:
> 
> 1. Is it appropriate to post this patch here, or should I be contacting 
> the maintainer of that
> package directly?

c.f. 
http://dev.catalyst.perl.org/browser/trunk/Catalyst/lib/Catalyst/Manual/DevelopmentProcess.pod

there isn't exactly any "the maintainer"

Here is fine though, or the catalyst-dev@ list maybe be better.

> 2. I created an instance variable _options to hold the options hash, 
> rather than passing it down
> into _handler() and then into _socket_data().  I was surprised it wasn't 
> already an instance variable.
> Is this an OK thing to do?  Is there a coding style standard somewhere?
> 
> 3. I also created an accessor method options() in 
> Catalyst::Engine::HTTP, but not a setter method.  I
> was surprised that C:E:HTTP didn't inherit from a superclass providing 
> generic accessor/setters for
> all the instance variables.  Was this an OK thing to do?

It does. Check the ISA list again :)

> Basically, if I want my patches to be rolled into the official Catalyst, 
> I need to know if I'm doing
> things appropriately.  Any constructive input is welcome.

Proper accessor, make sure it applies cleanly against current subversion 
trunk, and wait and see what the Engine experts think.

Plus a test case would be nice.



More information about the Catalyst mailing list