Closed Firstyear closed 1 month ago
I might actually re-target this to 2.5 and update to that branch during this process as it will make backporting easier :)
@Firstyear , what is a typical high wtime value ? wtime accounts the time spent in work-queue so that a worker picks the request. We identified that #4812 relieved the conntable contention but the server hits a next contention on the work-queue (listeners/workers are competing to access that queue). Could it be related to this issue ?
We're seeing 1 second or higher with op times below 0.001.
I'm aware of that issue and I have already found some defects in it's implementation that I plan to test and correct :)
see also #6326 (specific bug to measure iotime)
Issue Description Following #4812 a lot of improvements were made to scalability. Currently a major custom is testing 389-ds and is continuing to hit limitations. This mostly is around high wtimes under high connection load. The user is also seeing low CPU consumption and low etimes, indicating that issues still persist around the connection/worker handling code.
I plan to either backport missing performance fixes to 2.2, or to improve and add more improvements to 2.2 (and main).
Package Version and Platform: