> Am 11.05.2016 um 17:03 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > It seems like a lot of the scoreboard confusion lies in the event > MPM lies in the work-performed-by-thread model of the thread > based scoreboard. > > Let's call this existing model 'ExtendedStatus threads' > > What it seems some users and committers are looking for is > a different model, let's call this 'ExtendedStatus connections'.
I got some such feedback when h2 connections truly went async and no longer showed up as occupying a slot. I share your idea that in an event based server, threads are not the primary dimension but connections are. The information which thread handled a connection at which point in time seems irrelevant. If a connection occupies a thread for more than x seconds, it certainly becomes interesting. Also the waiting time, should all threads be occupied, is interesting as well as statistics about how many keepalive connections were closed early due to worker exhaustion. > If we adopted an ExtendedStatus connections, the scoreboard > table would be much larger than the number of event threads, > and would report all of the open connections to the server (at > least, all those that had passed the httpready threshold of our > awareness). It can't be a simple ring, because the slots would > expire at different times relative to their injection, so we would > probably want to track the oldest request. The most optimal > implementation would have score pools per-process so that > connection score slot reuse is a simple thread lock, but we > could alternately perform this tracking across processes. > > The first question that comes to mind is whether there is any > value in supporting ExtendedStatus threads+connections? > Two entire detailed lists residing in two different score shms? > Note that the traditional thread status flag scoreboard would > certainly be preserved, for a thread summary, even when the > user chooses ExtendedStatus connections. > > Feedback and more ideas? It seems the information which request had been processed is so interesting (which I totally destroyed in my ignorance) that scoreboard should make every attempt to keep it until it is replaced by something new. This is fine for the "static" HTML view that there is now. What I would find really cool is a feature that records connection/worker changes and lets me play that back in a browser. Maybe even a live feed of (a subset of) activities. Something that you see in the background on Star Trek, only it would be real. It could record individual deltas or snapshots at timed intervals. Not sure what is more feasible. I once did a status monitor of a system with various props that reported green/yellow/red and had that in a horizontal scroll in a browser. Customer was not happy as it became apparent how often his system was in red though...but that cannot happen to us! -Stefan
