Hi Team,
I am using Splunk for my analysis after running the script in Load runner. In Splunk query, I am using bucket span=1m_time which will give the results with 1 m interval starting from 0 to 59 seconds. Let say in a given minute, system should process only 60 requests. If I start my exection around x seconds other than 0, my 1 minutes time span will start from the x sec+59 seconds.
using bucket span, I always gets the results considering the start of the minute as 0 and end of the minute as 59. Please let me know is there a way to specify the start time of the minute with x seconds instead of standard 0 seconds.
Basically, if you want your minute spans to start at x=25 seconds after the minute, use something like this...
| eval _time = _time -25
| bucket _time span=1m
| eval _time = _time +25
Now that you understand, here's the efficient way, since it's streaming distributable.
| eval _time = 25+60*floor( (_time-25)/60)
... and if you want the low end to start exactly at the low end of your search time, then use addinfo and calculate it this way
| addinfo
| eval mysecond = floor(info_min_time) - 60*floor(info_min_time/60)
| eval _time = mysecond+60*floor( (_time-mysecond)/60)
...or possibly...
| addinfo
| eval _time = floor(info_min_time) + 60*floor((_time - info_min_time)/60)
Those two will give fractionally different results, but the second one should be slightly quicker, I would think.
Basically, if you want your minute spans to start at x=25 seconds after the minute, use something like this...
| eval _time = _time -25
| bucket _time span=1m
| eval _time = _time +25
Now that you understand, here's the efficient way, since it's streaming distributable.
| eval _time = 25+60*floor( (_time-25)/60)
... and if you want the low end to start exactly at the low end of your search time, then use addinfo and calculate it this way
| addinfo
| eval mysecond = floor(info_min_time) - 60*floor(info_min_time/60)
| eval _time = mysecond+60*floor( (_time-mysecond)/60)
...or possibly...
| addinfo
| eval _time = floor(info_min_time) + 60*floor((_time - info_min_time)/60)
Those two will give fractionally different results, but the second one should be slightly quicker, I would think.