progier389
commented
2 months ago I agree: we could easily test this one by writing a python test that use directly the socket API to send a trivial ldap request but split the ldap ber in at least two socket.send() waiting a few seconds between sending the PDUs)
The hardest thing to check is the time to read the results (er could also wait but the network buffer will probaly makes things more complex (maybe the result should be long enough to fill up the buffers ...)
Issue Description In access logs, high wtime is a sign of worker starvation and often leads to increase nsslapd-threadnumber. It may occur that high wtime is related to reading the client request rather then waiting for a worker. (see here)
The discussion kind of agree to keep wtime to time spent by a new request in the wait queue (waiting for a worker) while a new report 'iotime' would report the time spent by the selected worker to read the full request.
Package Version and Platform: all release
Steps to Reproduce Steps to reproduce the behavior: unknown. Possibly having a client sending request (large?) slowly
Expected results wtime should stick to time to get a worker iotime should report the time spent, by the worker, to read the request
Add any other context about the problem here.