Getting Data In

max throughputs of forwarders

MuS
SplunkTrust
SplunkTrust

dear sirs,

I'm aware about default limitations in a lightweight forwarder (256KB), which can be increased. it’s also clear to me that this depends on a lot of points, like sources (local disk, lan mount, lan interface speed, system performance etc.) and functionality (raw, lightweight and full forwarder).

what would be the critical throughput limit, that a forwarder could handle per second/minute/hour/day (practical experience) depending on functionality?

the question is related to forwarders which could send a huge amount of data within a short time range.

regards, michael

Tags (1)
1 Solution

MuS
SplunkTrust
SplunkTrust

had a little chat with mzorzi and we came up with the conclusion, that the throughput limit for a forwarder would be the network interface.

nevertheless, the indexer would be the bottleneck here, not the forwarder.

regards

View solution in original post

MuS
SplunkTrust
SplunkTrust

had a little chat with mzorzi and we came up with the conclusion, that the throughput limit for a forwarder would be the network interface.

nevertheless, the indexer would be the bottleneck here, not the forwarder.

regards

Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Splunk App Dev Quarterly Roundup: AI, Agents, and Innovation!

Another quarter, another wave of innovation. From complex integrations to pushing the limits ...

Federated Search for Dynamic Data Self Storage Is Now Generally Available on Splunk ...

 Splunk is excited to announce the General Availability of Federated Search for Dynamic Data Self Storage ...

Index This | What has many keys but can’t unlock a door?

July 2026 Edition  Hayyy Splunk Education Enthusiasts and the Eternally Curious!   We’re back with this ...