389 ds connection management proposal
by James Chapman
I have done some work on 389 ds connection management that I would
appreciate the community's feedback on, you can find attached a draft patch
Currently the connection table (CT) contains an array of established
connections that are monitored for activity by a single process. As the
number of established connections increase, so too does the overhead of
monitoring these connections. The single process that monitors established
connections for activity becomes a bottleneck, limiting the ability of the
server to handle new connections.
One solution <https://github.com/389ds/389-ds-base/issues/4812> to this
problem is to segment the CT into smaller portions, with each portion
having a dedicated thread to monitor its connections. But, rather than
divide the CT into smaller portions, the approach I prefered was to add
multiple active lists to the CT, where each active list would have its own
With a single thread monitoring each CT active list, connections can be
monitored in parallel, removing the bottleneck mentioned above.
Instead of a single CT active list containing all established connections,
there will be multiple CT active lists that share the total number of
established connections between them.
With this change I noticed a ~20% increase in the number of connections per
second the server can handle.
I tested this change with 100, 500, 1k, 5k and 10k concurrent connections,
I have found that having two CT active lists is the optimal config. I think
we should hardcode the CT active list number to two and have it hidden from
the user/sysadmin, or would it be better as a configurable parameter?
1 year, 5 months