Hi @Christian_Dahlqvist / @danielmitterdorfer,
I made quite some tests with the event-data-track.
My testrun was like the following:
- restart elasticsearch
- import 250 mio events via challenge elasticlogs-1bn-load
- do this 3x
- restart elasticsearch
- run challenge elasticlogs-querying.
- do this 5x
- restart elasticsearch
- run challenge combined-indexing-and-querying
- do this 2x
- restart elasticsearch
- run challenge [elasticlogs-querying](https://github.com/elastic/rally-eventdata-
When I check the service time of kibana queries during elasticlogs-querying I can see a massive spike at the beginning.
The image shows the service time of the 1st three iterations of elasticlogs-querying.
For me it looks like some warmup issue which occurs after massive writing. (maybe disk cache by OS?).
I just want to ask, why the warmup period is explicitly set to 0.
{
"parallel": {
"warmup-time-period": 0,
"time-period": 1800,
"clients": 4,
"tasks": [
{
"operation": "relative-kibana-content_issues-dashboard_50%",
"target-interval": 30
},
{
"operation": "relative-kibana-content_issues-dashboard_75%",
"target-interval": 90
},
{
"operation": "relative-kibana-traffic-dashboard_50%",
"target-interval": 40
},
{
"operation": "relative-kibana-discover_50%",
"target-interval": 60
}
]
}
Is there a deeper meaning behind that? What is it? I just would like to understand the decision
Regards, Andreas