You typically want response time to stay relatively constant regardless of how much traffic you’re serving. _sourceCategory=Apache/Access | parse regex "HTTP/1.1\"\s+\d+\s+(?\d+)" | parse regex "(?\d+)$" | timeslice 1m | microseconds/toLong(1000000) as seconds | (size/1024) as kbytes | avg(seconds) as response_time, sum(kbytes) as kbytes by _timesliceīy visualizing the traffic volume as columns and response time as a line graph, we can quickly determine if there’s a correlation between the two.Īverage response time and total traffic volume The following query includes the total bytes served every minute: To determine if this is the case for your Apache servers, we need to compare response time to traffic volume. Performance problems are often caused by a web application’s inability to scale. Analyzing Response Time and Traffic Volume You can chart 95 percentile response times, or you can set up alerts on it, so that you get paged whenever response time is much more than what you expect. Typically – you want to see the 95 percentile response times, in which case Sumo will offer a percentile operator which can be used like: *| parse "-*/*-" as seconds, micro_seconds
You can parse the times taken by running a parse command like: This article assumes you’ve defined the following LogFormat in your nf file and told Apache to use it for its access logs with the CustomLog directive: The process is similar to Apache Traffic Analysis, but now we can look at speed in addition to hits and volume. By comparing this information to the other fields in an Apache access log, we can uncover performance bottlenecks in a web application.
0 kommentar(er)
