HorseSpeed will compute the mean, median, standard deviation, and percentile(s) of the time-taken field in an IIS log.
HorseSpeed
will compute the mean
, median
, standard deviation
, and percentile(s)
of the time-taken
field in an IIS
log.
As the name indicates it, don’t take this project too seriously. I wrote it because I didn’t figure out a quick way to compute percentiles from an IIS
log.
Log Parser 2.2 needs to be installed on your machine. It is free and you’re most likely already using it anyway to query IIS
logs.
By default HorseSpeed
will compute the mean
, median
, standard deviation
, 50th percentile
, 70th percentile
and 95th percentile
.
HorseSpeed.exe "log-path" "where-clause"
log-path
could be D:\u_ex160510.log
where-clause
can be anything that is a valid WHERE
clause. A basic example is cs-uri-stem = '/legacy/SlowPage.aspx'
You can replace the default percentiles by your own:
HorseSpeed.exe "log-path" "where-clause" "5,50,99.99"
5th
, 50th
and 99.99th percentile
(on top of the mean
, median
and standard deviation
).The log-path
argument supports two different modes:
D:\u_ex160510.log
or D:\u_ex1605*.log
- will process all the files matching the filter and aggregate the result.D:\
will read all the files with the .log
extension in the D:\
directory (excluding sub directories) and process them separately.The ordered (ASC
) time-taken
resulting from the query can be written to .csv
files(s) so that you can generate all kind of crazy charts via Excel
.
To enable this feature add a WriteTimingFile
key with the value True
to the app.config
. It will then create CSV
file(s) in the .\out\
directory (relative to where the exe
is located).
I don’t want to use any NuGet
package except if I absolutely have to.
Statistics class: orderedList. Should I order it again just in case?
Testability issues could be fixed by introducing a level of indirection on the file system. But I would be modifying the design to allow testing.
Program.cs
.FileWriter
is not testable as it depends from FileSystem
. It’s an issue as GenerateOutFilePath
has logic.FileWriter
requires 2 calls to write output (as we want to know the generated filepath in order to inform the caller). I could return the filepath from WriteTimingFile
but this would break the Command Query
separation.GetFromClauses
is hanging from Program.cs
right now.GetFromClauses
is not testable as it has a dependency on file system.