If you have enabled splunk S2S compression, you can skip reading further.  compressed = true TLS 1.3 removed  compression and as a result it will have a huge impact on your deployment if still using following for  compression in tcpout outputs.conf. useClientSSLCompression=true  If you adopt TLS 1.3 on indexing/IF trier, then it's possible you are still having legacy/unsupported forwarder versions(6.0 and above). Those forwarders will suddenly flood network traffic due to TLS 1.3 on the indexing tier/IF tier. I would strongly suggest don't wait and add compressed = true ASAP in outputs.conf even if there are no plans for TLS 1.3 adoption. You will have following configs, compressed = true useClientSSLCompression = true   As long as target supports SSL compression, your legacy old forwarder will use useClientSSLCompression. However the moment target indexer/IF adopts TLS 1.3, legacy old forwarder will fallback to compressed.  By doing this, Indexer/IF tier adoption to TLS 1.3 will not result in flooding networks due to sudden uncompressed traffic. Note:  Currently Splunk do not support TLS 1.3. However it's coming soon.   ... View more

Here are the configs for on-prem customers willing to apply and avoid adding more hardware cost. 9.4.0 and above most of the indexing configs are automated that’s why dropped from 9.4.0 suggested list. Note: Assuming replication queue is full for most of the indexers and as a result indexing pipeline is also full however indexers do have plenty of idle cpu and IO is not an issue. On-prem Splunk version 9.4.0 and above Indexes.conf [default] maxMemMB=100 Server.conf [queue] autoAdjustQueue=true ( It can be applied on on any splunk instance UF/HF/SH/IDX) Splunk version 9.1 to 9.3.x Indexes.conf [default] maxMemMB=100 maxConcurrentOptimizes=2 maxRunningProcessGroups=32 processTrackerServiceInterval=0 Server.conf [general] parallelIngestionPipelines = 4 [queue=indexQueue] maxSize=500MB [queue=parsingQueue] maxSize=500MB [queue=httpInputQ] maxSize = 500MB maxMemMB, will try to minimize creation of tsidx files as much as possible at the cost of higher memory usage by mothership(main splunkd). maxConcurrentOptimizes, on indexing side it’s internally 1 no matter what the setting is set to. But on target replication side launching more splunk-optimize processes means pausing receiver until that splunk-optimize process is launched. So reducing it to keep receiver do more of indexing work than launching splunk-optimize process. With 9.4.0, both source (indexprocessor) and target(replication in thread) will internally auto adjust it to 1. maxRunningProcessGroups, allow more splunk-optimize processes concurrently. With 9.4.0, it's auto. processTrackerServiceInterval, run splunk-optimize processes ASAP. With 9.4.0, you don't have to change. parallelIngestionPipelines, have more receivers on target side. With 9.4.0, you can enable auto scaling of  pipelines. maxSize, don’t let huge batch ingestion by HEC client block queues and receive 503. With 9.4.0 autoAdjustQueue set to true, it's no more a fix size. ... View more

Here are the configs for on-prem customers willing to apply and avoid adding more hardware cost. 9.4.0 and above most of the indexing configs are automated that’s why dropped from 9.4.0 suggested list. Note: Assuming replication queue is full for most of the indexers and as a result indexing pipeline is also full however indexers do have plenty of idle cpu and IO is not an issue. On-prem Splunk version 9.4.0 and above Indexes.conf [default] maxMemMB=100 Server.conf [queue] autoAdjustQueue=true Splunk version 9.1 to 9.3.x Indexes.conf [default] maxMemMB=100 maxConcurrentOptimizes=2 maxRunningProcessGroups=32 processTrackerServiceInterval=0 Server.conf [general] parallelIngestionPipelines = 4 [queue=indexQueue] maxSize=500MB [queue=parsingQueue] maxSize=500MB [queue=httpInputQ] maxSize = 500MB maxMemMB, will try to minimize creation of tsidx files as much as possible at the cost of higher memory usage by mothership(main splunkd). maxConcurrentOptimizes, on indexing side it’s internally 1 no matter what the setting is set to. But on target replication side launching more splunk-optimize processes means pausing receiver until that splunk-optimize process is launched. So reducing it to keep receiver do more of indexing work than launching splunk-optimize process. With 9.4.0, both source (indexprocessor) and target(replication in thread) will internally auto adjust it to 1. maxRunningProcessGroups, allow more splunk-optimize processes concurrently. With 9.4.0, it's auto. processTrackerServiceInterval, run splunk-optimize processes ASAP. With 9.4.0, you don't have to change. parallelIngestionPipelines, have more receivers on target side. With 9.4.0, you can enable auto scaling of  pipelines. maxSize, don’t let huge batch ingestion by HEC client block queues and receive 503. With 9.4.0 autoAdjustQueue set to true, it's no more a fix size queue. ... View more