Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

Very long request time weirdness

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


luke.saunders at gmail

Jun 24, 2008, 8:50 AM

Post #1 of 2 (364 views)
Permalink
Very long request time weirdness

In order to get some info on how long requests were taking and where
the bottlenecks were we put some code into MyApp::finalize which wrote
info gained from $c->stats to the DB so we could easily check them
later (code given below). Occasionally we get a request where total
time ($c->stats->elapsed) is very long (more than 50 seconds) but each
individual action executes very quickly (they usually sum to less than
1 second). So presumably something is happening between the end action
and finalize which is taking ages, but what on earth could that be?

This is Catalyst::Runtime 5.7014 running on a Fastcgi system. This
only affects about 3 out of 35000 requests, but I'd still like to know
why it's happening. Any ideas?

sub finalize {
my $c = shift;

$c->NEXT::finalize( $c, @_ );
return if $c->_static_file; # don't bother logging the serving of
static files
return unless $c->config->{request_logging};

my $request_log = {
browser => $c->req->browser->browser_string(),
browser_version => $c->req->browser->version(),
path => join('', '/', $c->req->path),
params => join('&', map { $_ . "=" . $c->req->params->{$_} } keys
%{$c->req->params}),
total_time => $c->stats->elapsed,
total_sql_time => sprintf('%0.6f',
$c->model('123peopleDB')->querylog->time_elapsed),
query_count => $c->model('123peopleDB')->querylog->count
};
my $log_req_obj = $c->model('123peopleDB::LogRequest')->create($request_log);

my @request_stages = $c->stats->report;
foreach my $stage (@request_stages) {
my $request_stage_log = {
depth => $stage->[0],
stage_name => ($stage->[3] ? '(Action) ' : '(Other) ') . $stage->[1],
total_time => $stage->[2],
total_sql_time => 0,
query_count => 0
};
$log_req_obj->related_resultset('stages')->create($request_stage_log);
}
}

_______________________________________________
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/


jon at jrock

Jun 24, 2008, 9:28 AM

Post #2 of 2 (340 views)
Permalink
Re: Very long request time weirdness [In reply to]

* On Tue, Jun 24 2008, luke saunders wrote:
> In order to get some info on how long requests were taking and where
> the bottlenecks were we put some code into MyApp::finalize which wrote
> info gained from $c->stats to the DB so we could easily check them
> later (code given below). Occasionally we get a request where total
> time ($c->stats->elapsed) is very long (more than 50 seconds) but each
> individual action executes very quickly (they usually sum to less than
> 1 second). So presumably something is happening between the end action
> and finalize which is taking ages, but what on earth could that be?

Feeding data to an end-user with a slow connection? I assume your
frontend server would buffer that, but who knows?

Perhaps you can get the number of CPU seconds your process has used at
the beginning of the request (around prepare or execute) and then again
before writing data to the log, to see if you are CPU bound those 50
seconds. If you are, then your problem is the app. If you aren't, then
the problem is IO.

You might also want to log the size of the data you're returning. If
you see no CPU usage, and the response body is huge, this further points
towards IO being a problem.

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"

_______________________________________________
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/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.