Latency baised Hermes configurationOut of the box, Hermes is tuned for higher throughput. We have some properties and configurations we can use to be able to prioritize latency over throughput.We can use the following configurations:-Out of the box configurations:Inbound Stream Concurrency: 2Log Stream Concurrency: 1Partitions: 32Scheduled job configuration:KafkaConsumerJob Repeat: 5sSystem properties configuration:glide.ih.kafka.consumer.max_seconds_per_session: 300glide.ih.kafka.partition_group_backoff_time_seconds: 0glide.ih.kafka.consumer.max_seconds_per_partition_group: 1Lets delve a bit deeper into these changes. The concurrency is set to a combined value of 3 across our two streams of Inbound(used for events/alarms/metadata) and the other stream of Log(used for errors and logs) being received from the edge.We are keeping this concurrency value to a small number to minimise the impact on the ServiceNow especially on smaller instances.Kafka partitions are set to 32. This is the max value supported and will help in managing large loads from many different sources as and when required.KafkaConsumerJob repeat interval is a value used for restarting the KafkaConsumerJob when the previous one expires. We are setting it to a value of 5 seconds rather than the default of 55 seconds to minimise any potential downtime. This can be configured via the sys_trigger table for the various KafkaConsumerJob jobs.The sys properties mentioned are used for tuning Stream Connect. These help us in reducing latency. They are used to configure the max time a KafkaConsumerJob runs at a time (useful for prevent long running job) and set the maximum idle time. It reduces the time Stream Connect waits on a single partition especially if no new messages are received in that partition. Available via attached update set.This way we can configure the Stream Connect and Hermes setup to prioritize latency over throughput.