A variety of undifferentiated work is carried out on general purpose worker threads, including sending over a network, authentication, and completion of HTTP requests.
Increasing the number of threads beyond that necessary to satisfy the workload generated by other components in the system may result in additional unnecessary context switching overhead.
Reader threads count
Reader threads are used for all read operations on data files - whether the requests originate from the client or from internally to the database. There are a number of things that cause operations to be dispatched to reader threads, including:
- All index reads, including those to service stream and event number-based reads and for idempotent handling of write operations when an expected version is specified.
- Data to service requests originating from either the HTTP or TCP client APIs.
- Projections needing to read data for processing.
- Authorization needing to read access control lists from stream metadata.
Reads are queued until a reader thread becomes available to service them. If an operation doesn't complete within an internal deadline window, a disk operation is not dispatched by the worker thread which processes the operation.
Effect on reads
The size of read operations is dependent on the size of the events appended, not on the database chunk size, which has a fixed logical size. Larger reads (subject to the operating system page size) result in more time being spent in system calls, and less availability of reader threads.
Increasing the readers count
A higher reader count can be useful, if disks are able to support more concurrent operations. Context switching incurs additional costs in terms of performance. If disks are already saturated, adding more reader threads can exacerbate that issue and lead to more failed requests.
Increasing the count of reader threads can improve performance up to a point, but it is likely to rapidly tail off once that limit is reached.