httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonyou, Austin" <>
Subject RE: perf tuning (RE: test harness for Apache)
Date Sat, 07 Jul 2001 20:28:09 GMT
You can just get the SAR and SYSSTAT sources and compile it for almost ANY
platform now. You can also use perfmon on NT/2K/XP, to do that as well. (it
IS much harder on those platforms though)

Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023

> -----Original Message-----
> From: Brian Pane []
> Sent: Saturday, July 07, 2001 12:56 PM
> To:
> Subject: Re: perf tuning (RE: test harness for Apache)
> dean gaudet wrote:
> >On Thu, 5 Jul 2001 wrote:
> >
> >>Does anyone know the best way/methods/tools to monitor web 
> applications
> >>running on Apache written in java, jsp and some CGI?  Is 
> server-status good?
> >>Any hints on what to look for?  Any books on performance or 
> white papers?  I
> >>need to isolate performance problems on the webserver - 
> would like to not
> >>have to spend $$ for additional monitoring tools.
> >>
> >
> >i get a lot of mileage out of the standard tools that come 
> with each unix.
> >
> >"vmstat 5" is usually the first thing i type on a system with a
> >performance problem.  i eschew "top" 'cause it doesn't give 
> you the info
> >in a useful format.
> >
> On platforms where it's available, I also highly recommend 
> sar; running 
> its collector
> program frequently (e.g., every couple of minutes) gives you 
> some nice 
> historical data
> on memory usage, paging, CPU usage, forks/second, execs/second, and 
> more.  Just as
> vmstat is useful if you want to know why the web server is slow right 
> now, sar is
> useful if someone asks why the web server was slow yesterday 
> afternoon.
> >strace or truss are usually the second thing i go for.
> >
> >your jvm may reduce the usefulness of strace -- it may be 
> difficult to
> >piece together what syscalls are for which request.  
> strace/truss work at
> >the kernel syscall level, which is higher than the thread 
> level in some
> >unixes (i.e. solaris).
> >
> I've also found it useful to get a stack trace of the apps in 
> question, 
> on platforms
> and environments where the needed tools exist.  On Solaris, 
> for example, 
> /usr/proc/bin/pstack
> is great for getting the C stack trace of any running process.  It's 
> sometimes useful as
> a crude profiling tool; if you have a multiprocess httpd, or a lot of 
> instances of a CGI
> program running concurrently, or a multithreaded JVM, you can grab a 
> stack trace for
> every thread; if a large percentage of processes/threads are 
> in a given 
> code path, that's
> often where the bottleneck is.
> For routine monitoring, one of my favorite metrics is the number of 
> requests being
> handled concurrently by each part of the system (web server, 
> application 
> server, database,
> etc).  For anything that uses a TCP connection for each 
> request, you can 
> run netstat
> periodically to count connections in established state on 
> each port of 
> interest.  A
> sudden, large jump in the count of established connections usually 
> indicates trouble--
> either a spike in incoming traffic or a bottleck on the server that 
> slows down the
> handling of an otherwise normal traffic load.  (It's also useful to 
> count connections
> in close_wait at the same time, of course.)
> --Brian

View raw message