Throttling

slskd is a multi-threaded application and the logic is highly concurrent, but is mostly bound by disk and network I/O rather than CPU.

The concurrency option controls how many threads (.NET Tasks to be specific) can perform work at the same time, limiting I/O contention. Raising the number can improve throughput on capable machines but defaults are generally set in such a way that improvements will be negligible. Lowering the number will reduce throughput but alleviate I/O contention and improve stability on lower-spec hardware.

Lower values of concurrency or slow processing of individual messages may cause the application to process messages at a slower rate than they are received, causing messages to be 'backed up' in internal queues. The circuit_breaker option controls the number of messages that can be enqueued. Once the circuit breaker is hit, the application will drop or discard messages without processing them.

The latency, queue depth and rate at which messages are being dropped can be monitored by reviewing the application state or Prometheus metrics.

YAML

throttling:
  search:
    incoming:
      concurrency: 10 # number of search requests to process at the same time
      circuit_breaker: 500 # maximum number of pending search requests
      file_limit: 500 # maximum number of files to return in a single search response

Additional Metrics

Search Requests

• slskd_search_incoming_requests_received - Total number of search requests received
• slskd_search_incoming_request_receive_rate_current - Number of search requests received in the last minute
• slskd_search_incoming_requests_dropped - Total number of search requests dropped due to processing pressure
• slskd_search_incoming_request_drop_rate_current - Number of search requests dropped in the last minute
• slskd_search_incoming_request_queue_depth_current - The number of incoming search requests waiting to be processed

Search Responses

• slskd_search_incoming_responses_sent - Total number of search responses sent
• slskd_search_incoming_response_send_rate_current - Number of search responses sent in the last minute

Search Response Latency

The time it is taking to respond to incoming search requests. The ideal rate is something under ~30ms, or dropped requests become likely.

The response_latency metric is a measure of the total time, from receipt of the request until the response is returned. The remaining metrics measure different components of the overall latency.

• slskd_search_incoming_response_latency - The time taken to resolve and return a response to an incoming search request, in milliseconds
• slskd_search_incoming_response_latency_current - The average time taken to resolve and return a response to an incoming search request, in milliseconds
• slskd_search_incoming_filter_latency - The time taken to apply filters to an incoming search request, in milliseconds
• slskd_search_incoming_filter_latency_current - The average time taken to apply filters to an incoming search request, in milliseconds
• slskd_search_incoming_query_latency - The time taken to query share database(s) for results, in milliseconds
• slskd_search_incoming_query_latency_current - The average time taken to query share database(s) for results, in milliseconds