On 9 Oct 2019, at 19:55, Ludwig Krispenz <lkrispen(a)redhat.com>
wrote:
Hi William,
I like your radical approach :-)
In my opinion our connection code is getting to complicated by maintaining two different
implementations in parallel - not separated, but intermangled (and even more complicated
by turbo mode). So I agree we should have only one, but which one ? In my opinion nunc
stans is the theoretically better approach, but nobody is confident enough to rely on nunc
stans alone. The conntable mode has its problems (especially if handling many concurrent
connections, and worse if they are established almost at the same time)(otherwise we would
not have experimented with nunc stans), but is stable and for most of the use cases
efficient enough.
I think you nailed it in one - we aren't confident in nunc-stans today, so let's
keep what works and improve that. There are already many similar concepts - work queues,
threads, even slapi_conn_t. I think that it would be possible to bring "nunc-stans
ideas" into reworking and improvement to the current connection code instead.
So reducing the complexity by removing nunc stans (and maybe also turbo mode) and then do
cleanup and try to improve the bottlenecks would be an acceptable approach to me.
Agree. It also means we can make much smaller changes in an easier to control and test
fashion I think.
In my opinion the core of the problem of the "old" connection code is that the
main thread is handling new connections and already established connections and so does
iterate over the connection table. Using an event model looks like the best way to handle
this, but if it doesn't work we need to look for other improvements without breaking
things.
Your suggestion to make the conn table data structure more lean and flexible is one
option. In sun ds, when I didn't know about event queues I did split the main thread,
one handling new connections and multiple to handle established connections (parts of teh
conn table) - reusing the existing mechanisms, just splitting the load. Maybe we can also
think in this direction.
I think so too. We can certainly have some ideas about what actually does the polling vs
what does accepting, or better, event management etc. There are some ideas to have smaller
groups of workers too to improve thread locality and help improve concurrency too.
So maybe I'll put together a patch to remove nunc-stans soon then, and start to look
at the existing connection code and options to improve that + some profiling.
I still would like to hear about my original question though as quoted below, I think Mark
might have some comments :)
> The main question is *why* do we want it merged?
> Is it performance? Recently I provided a patch that yielded an approximate ~30% speed
up in the entire server through put just by changing our existing connection code.
> Is it features? What features are we wanting from this? We have no complaints about
our current threading model and thread allocations.
> Is it maximum number of connections? We can always change the conntable to a better
datastructure that would help scale this number higher (which would also yield a
performance gain).
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs