This discussion is archived
2 Replies Latest reply: Oct 19, 2012 9:14 AM by 802907 RSS

How to analyse etime values from access log files

951873 Newbie
Currently Being Moderated
Everytime my directory server respond to a query, one entry of etime is recorded in logs file, as follow:
etime=0.000180
etime=0.002980
etime=0.003260
etime=0.003010
etime=0.000170
....
.....

So how can we calculate our directory server or service's performance on basis of etime values? Let's say, if we think that etime >= 10 milisec. is not good. Then can we do like this?
more <logfile> | grep "19/Oct/2012" | grep etime | awk -F" " '{print $11}' | wc -l
So it will give us count of total etime values. let's say it is 10000.
After this we count total etime values that are greater than or equal to 10 milisec i.e. 0.01 sec.:
more <logfile> | grep "19/Oct/2012" | grep etime | awk -F" " '{print $11}' | awk 'etime>=0.01' | wc -l
And suppose it gives me, 2000
Then can I do:
"(2000x100)/10000" to get percentage of etime that was greater than 10ms? Or "100-(2000x100)/10000" to get total etime that was less than 10ms?
Can this thing give me any helpful results, so I can then imrpove my dir. server performance, i.e it's etime performance?
Thanks in advance for any help!!
  • 1. Re: How to analyse etime values from access log files
    Marco Milo Journeyer
    Currently Being Moderated
    Hello,
    Directory Server already comes with a general purpose log analyzing and reporting tool: logconv.pl [shipped by default with ODSEE under <INSTALL_DIR>/dsrk/bin/ ]

    Give it a try, as it's generally a good starting point to spot out the top highest etimes and the most busy clients.

    HTH,
    marco
  • 2. Re: How to analyse etime values from access log files
    802907 Journeyer
    Currently Being Moderated
    The access log analysis is good, but it really needs to be interpolated into your system resource monitors. What you want to find out is, for example, whether a spike in response time correlates with a spike in CPU utilization, disk I/O latency, incoming connections, or raw workload. This will enable you to determine where the root cause really is, which is pretty much a prerequisite for arriving at a deliberate solution.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points