FAQ
I'm getting very high times when running my Catalyst application in
standalone mode. I used Devel::NYTProf and zeroed in on a few subs in
Catalyst::Engine::HTTP which take long:

Catalyst::Engine::HTTP::_socket_data: 678s(exclusive) 678s(inclusive)
Catalyst::Engine::HTTP::run: 55.5s(exclusive) 735s(inclusive)
Catalyst::Engine::HTTP::_handler: 12.5ms(exclusive) 679s(inclusive)

On closer inspection of _socket_data, I find the following taking lots of
time (678 seconds):

519 my $data = {
520 peername => $iaddr
521 ? ( gethostbyaddr( $iaddr, AF_INET ) || 'localhost'
)
522 : 'localhost',
523 peeraddr => $iaddr
524 ? ( inet_ntoa($iaddr) || '127.0.0.1' )
525 : '127.0.0.1',
526 localname => gethostbyaddr( $localiaddr, AF_INET ) || 'localhost',
527 localaddr => inet_ntoa($localiaddr) || '127.0.0.1',

In the run subroutine, the following takes long (55 seconds):

254 while ( accept( Remote, $daemon ) ) {

My Perl package versions are:

Catalyst::Action::RenderView version: 0.04
Catalyst::Runtime version: 5.71001
Catalyst::Model::Adaptor version: 0.03
Catalyst::Plugin::ConfigLoader version: 0.23
Catalyst::Plugin::Session version: 0.20
Catalyst::Plugin::Session::State::Cookie version: 0.10
Catalyst::Plugin::Session::Store::FastMmap version: 0.07
Catalyst::Plugin::Static::Simple version: 0.21
Catalyst::Plugin::Authentication version: 0.10011
Catalyst::Plugin::Authentication::Store::LDAP version: 0.0601
Catalyst::Plugin::RedirectAndDetach version: 0.03
Catalyst::Plugin::Prototype version: 1.33
Catalyst::View::TT version: 0.29
Config::General version: 2.42
Mail::Box version: 2.088
Moose version: 0.74
parent version: 0.221
IO::Simple version: 0.04
Template::Plugin::Page version: 0.10
Template::Plugin::Date version: 2.77

Am I missing something or is this a bug?

--
Regards, Terence.
http://www.deeproot.in
Ph: +91 (80) 4089 0000

Search Discussions

  • Peter Edwards at Apr 20, 2009 at 9:42 am
    Terence,
    2009/4/20 Terence Monteiro <terence@deeproot.co.in>
    I'm getting very high times when running my Catalyst application in
    standalone mode. I used Devel::NYTProf and zeroed in on a few subs in
    Catalyst::Engine::HTTP which take long:
    Is your DNS set up correctly to reverse lookup the IP address you are
    testing from? If not the gethostbyaddr() will wait until it times out.

    Regards, Peter
    http://perl.dragonstaff.co.uk
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090420/8ad406c5/attachment.htm
  • Andrew Rodland at Apr 20, 2009 at 10:08 am

    On Monday 20 April 2009 04:35:05 am Terence Monteiro wrote:
    I'm getting very high times when running my Catalyst application in
    standalone mode. I used Devel::NYTProf and zeroed in on a few subs in
    Catalyst::Engine::HTTP which take long:
    The times for accept are because accept is the function that waits for a new
    incoming connection -- not a bug, 100% expected. The time spent in inet_ntoa
    is your system DNS resolver choking while trying to reverse-lookup the source
    IP address of the request. Most likely situation: you're using RFC1918
    addresses and your network is set up improperly to do DNS for these. If you
    can't fix this, hosts file entries might alleviate the problem.

    Andrew
  • Ian Wells at Apr 20, 2009 at 11:26 am

    2009/4/20 Andrew Rodland <arodland@comcast.net>:
    The time spent in inet_ntoa
    is your system DNS resolver choking while trying to reverse-lookup the source
    IP address of the request. Most likely situation: you're using RFC1918
    addresses and your network is set up improperly to do DNS for these. If you
    can't fix this, hosts file entries might alleviate the problem.
    I wouldn't necessarily assume that everyone has reverse lookup DNS on
    their test network. (Mine certainly doesn't, and I've been bitten by
    this slowing things down in the last few days.) Is there any chance
    we could make this lookup configurable?

    --
    Ian.
  • Andrew Rodland at Apr 20, 2009 at 12:04 pm

    On Monday 20 April 2009 06:26:57 am Ian Wells wrote:
    2009/4/20 Andrew Rodland <arodland@comcast.net>:
    The time spent in inet_ntoa
    is your system DNS resolver choking while trying to reverse-lookup the
    source IP address of the request. Most likely situation: you're using
    RFC1918 addresses and your network is set up improperly to do DNS for
    these. If you can't fix this, hosts file entries might alleviate the
    problem.
    I wouldn't necessarily assume that everyone has reverse lookup DNS on
    their test network. (Mine certainly doesn't, and I've been bitten by
    this slowing things down in the last few days.) Is there any chance
    we could make this lookup configurable?
    You don't need to have reverse DNS, you just need to not have a _broken_ DNS
    setup. Queries for RFC1918 addresses should fail NXDOMAIN instantly (or return
    success, of course). It's only when things are misconfigured that you get a
    slow SERVFAIL, in which case you can patch it up by setting up some (non-
    broken) local DNS or fooling with hosts.

    Anyway, looking at the source of 5.8001 it looks like reverse-lookup on the
    remote address has already been removed from Catalyst::Engine::HTTP::_sockaddr
    -- the remote hostname is produced lazily only when $c->req->hostname is
    called. Engine::HTTP only calls gethostbyaddr on the local bind address, which
    in all fairness really ought to work -- although perhaps an exception could be
    made to force "localhost" without actually doing (and failing) the lookup in
    the case of INADDR_ANY?

    Andrew
  • Matt S Trout at Apr 20, 2009 at 1:33 pm

    On Mon, Apr 20, 2009 at 01:26:57PM +0200, Ian Wells wrote:
    2009/4/20 Andrew Rodland <arodland@comcast.net>:
    The time spent in inet_ntoa
    is your system DNS resolver choking while trying to reverse-lookup the source
    IP address of the request. Most likely situation: you're using RFC1918
    addresses and your network is set up improperly to do DNS for these. If you
    can't fix this, hosts file entries might alleviate the problem.
    I wouldn't necessarily assume that everyone has reverse lookup DNS on
    their test network. (Mine certainly doesn't, and I've been bitten by
    this slowing things down in the last few days.) Is there any chance
    we could make this lookup configurable?
    Depends if you're going to write the patch - I don't have any networks with
    broken DNS to test on so I can't really do it ...

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
  • Ian Wells at Apr 21, 2009 at 8:10 am

    2009/4/20 Matt S Trout <dbix-class@trout.me.uk>:
    Depends if you're going to write the patch - I don't have any networks with
    broken DNS to test on so I can't really do it ...
    I wasn't aware I did either, but there you go.

    I'll keep quiet and update to 5.8 instead, I think. Seems like the
    easier solution.

    --
    Ian.
  • Matt S Trout at Apr 21, 2009 at 11:42 am

    On Tue, Apr 21, 2009 at 10:10:54AM +0200, Ian Wells wrote:
    2009/4/20 Matt S Trout <dbix-class@trout.me.uk>:
    Depends if you're going to write the patch - I don't have any networks with
    broken DNS to test on so I can't really do it ...
    I wasn't aware I did either, but there you go.

    I'll keep quiet and update to 5.8 instead, I think. Seems like the
    easier solution.
    Can you put something on the wiki as well please?

    People keep asking for this, getting it explained to them, deciding not to
    write a patch and then vanishing - it'd be really nice if you could explain
    things somewhere in such a way that hopefully the next guy can reach
    enlightenment without us having to go over it again :)

    --
    Matt S Trout Need help with your Catalyst or DBIx::Class project?
    Technical Director http://www.shadowcat.co.uk/catalyst/
    Shadowcat Systems Ltd. Want a managed development or deployment platform?
    http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 20, '09 at 9:35a
activeApr 21, '09 at 11:42a
posts8
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase