Return-Path: Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: (qmail 1559 invoked from network); 30 Mar 2009 11:46:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Mar 2009 11:46:39 -0000 Received: (qmail 77921 invoked by uid 500); 30 Mar 2009 11:46:37 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 77876 invoked by uid 500); 30 Mar 2009 11:46:37 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 77868 invoked by uid 99); 30 Mar 2009 11:46:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2009 11:46:37 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rolf.b.mr@gmail.com designates 209.85.220.177 as permitted sender) Received: from [209.85.220.177] (HELO mail-fx0-f177.google.com) (209.85.220.177) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2009 11:46:29 +0000 Received: by fxm25 with SMTP id 25so1894209fxm.10 for ; Mon, 30 Mar 2009 04:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=L38vhZHcdYOLwBCiNfeHUQ1hLsbDayJVxa/lXDB6aoY=; b=iDbkUmbtYiInvIqucwrb44KN//h5rqNk6Cq325qRl9BsEaOPyJhldLD4OcavU0kJQe V0+PCUVo57VCarnVNJnjF0VE4/RhxGVzc+LSHPGcK7I7soa2J3tk+Eog9SyIamugYwwB AdXvUJGggimT9nozWYZ6zsLB3ToV8YaLWs8qY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=P/orzDL1z8DlPOM+yGjbj6plVYi4i6g6+em+8dZnzWxLCHKAu8Mo86ovPV2Vcejpcb LRk//lFkov56jdJiHfMAd8LO1QJfiELqJsotEL74c55jfCKgBJg76dsksuIgd7aSc2Pg zIK/mFfYmRxZeJur1JXr5pqKwc5LZGuFQsJao= MIME-Version: 1.0 Received: by 10.204.116.208 with SMTP id n16mr1935864bkq.96.1238413569628; Mon, 30 Mar 2009 04:46:09 -0700 (PDT) In-Reply-To: <66887a3d0903291352p2e327b99if8774150aff32efb@mail.gmail.com> References: <66887a3d0903291334i139c9c39s16e8bdbcb5bba740@mail.gmail.com> <66887a3d0903291352p2e327b99if8774150aff32efb@mail.gmail.com> Date: Mon, 30 Mar 2009 12:46:09 +0100 Message-ID: <7e79c5b90903300446t42ea7229q19aedc3d75b318ee@mail.gmail.com> Subject: Re: Profiling live mod_perl backends From: Rolf Banting To: Perrin Harkins Cc: Cosimo Streppone , Mod_perl users Content-Type: multipart/alternative; boundary=0016e6d588d2e71b5c046654a075 X-Virus-Checked: Checked by ClamAV on apache.org --0016e6d588d2e71b5c046654a075 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Mar 29, 2009 at 9:52 PM, Perrin Harkins wrote: > On Sun, Mar 29, 2009 at 4:44 PM, Cosimo Streppone > wrote: > > The main problem is that in the past we experienced some kind of > > performance problems that only manifested themselves really clearly > > in production and only at peak traffic hours. > > Out of peak hours, everything was fine. > > That sounds like a problem with a shared resource like the database, > not something you'll find by profiling the code. You'd be better off > either using DBI::Profile or using logging on your database to find > the problem. > > - Perrin There's a neat idea in "Perl Hacks" where you nominate every 100th (or whatever) object as a debug object. Perhaps you could do something similar with Devel::NYTProf - profile only every 'n' th request during peak times. I assume you have checked "obvious" things like cpu & disk usage stats, KeepAlive, MaxClients etc --0016e6d588d2e71b5c046654a075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Mar 29, 2009 at 9:52 PM, Perrin = Harkins <pharkin= s@gmail.com> wrote:
On Sun, Mar 29, 2009 at 4:44 PM, Cosimo Streppone <cosimo@streppone.it> wrote:
> The main problem is that in the past we experienced some kind of
> performance problems that only manifested themselves really clearly > in production and only at peak traffic hours.
> Out of peak hours, everything was fine.

That sounds like a problem with a shared resource like the database,<= br> not something you'll find by profiling the code. =A0You'd be better= off
either using DBI::Profile or using logging on your database to find
the problem.

- Perrin

There's a neat idea in "Perl = Hacks" where you nominate every 100th (or whatever) object as a debug = object. Perhaps you could do something similar with Devel::NYTProf - profil= e only every 'n' th request during peak times.

I assume you have checked "obvious" things like cpu & dis= k usage stats, KeepAlive, MaxClients etc


--0016e6d588d2e71b5c046654a075--