This message originated from Cribl Community Slack.
Click here to view the original link.
Hi! Do you know if there is any type of performance advantage on using quickconnect instead of routes besides the fact of avoiding filter testing for each route? In my mental model, a quickconnect entry is a route that takes the input id as filter, but i wonder if there is a non-negligible difference in terms of performance.
Solved
Quickconnect Performance Advantage Over Routes Inquiry
Best answer by dbizon539
Theyre essentially the same engine under the hood - once youre in the pipeline, the work is identical and it doesnt care whether it came from the route or quickconnect.
Its pretty much negligible at best - the only overhead that it saves on is going through the routing table (which is nothing compared to pipelines/destination latency).
Outside of that - there may be an edge case where you use the route to send to a pack that also has a route (so doing double routing). This would still only save on the initial route configuration but that is still negligible and more of an architectural thing than performance.
The simple way to think about it (generally):
- Use QuickConnect for simple, parallel flows where all data from a source goes to defined destination(s) with optional pipelines/packs.
- Use Routes when you need complex filtering, cloning, cascading, or fine-grained control over multiple pipelines/destinations.
Theyre essentially the same engine under the hood - once youre in the pipeline, the work is identical and it doesnt care whether it came from the route or quickconnect.
Its pretty much negligible at best - the only overhead that it saves on is going through the routing table (which is nothing compared to pipelines/destination latency).
Outside of that - there may be an edge case where you use the route to send to a pack that also has a route (so doing double routing). This would still only save on the initial route configuration but that is still negligible and more of an architectural thing than performance.
The simple way to think about it (generally):
- Use QuickConnect for simple, parallel flows where all data from a source goes to defined destination(s) with optional pipelines/packs.
- Use Routes when you need complex filtering, cloning, cascading, or fine-grained control over multiple pipelines/destinations.
Thanks a lot for the explanation. I was about to write, for confirmation, almost what you just sent. :sweat_smile:
I was going to say the only performance boost you get is from the drag and dropping
The question was just in case I was missing something… because I see too many deployments where people avoid routes and force themselves to play just with quickconnects.
Oh, don’t get me started with scenarios with dozens of crowdstrike ngsiem destinations :grimacing:
Adding to that:
If you are planning to use the Projects feature, please use Routes. It won't work with QuickConnect
Yes, thank you. I use routes by default. :slightly_smiling_face:
(I would say always)
Sign up
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.