Thinking out loud here. Reading the source of mod_status and event some more:
- mpm_event: process_socket gets an available worker yanked and that means that connections walk all over the server slots during processing. - Columns in the Extended status really tell what the slot was doing and are not about a connection as such. The same connection will appear in different snapshots on many slots during its lifetime. This works nice for connections that rarely enter KEEPALIVE, e.g. process_connection() returns to the MPM. The new mod_http2 implementation now *often* returns to the MPM. Which means that connections "walk" across scoreboard slots in "server-status" and it is a bit hard to follow. hmmm...what to do? > Am 02.12.2021 um 10:40 schrieb Stefan Eissing <ste...@eissing.org>: > > Friends of the scoreboard, > > trying to improve the mod_http2 information available on our scoreboard, I am > not sure I can interpret correctly what I see. Maybe someone can help me? > > I run a 2.4.51 and see what worker are busy with. That#s fine. But I also see > slots where the connection has been closed a while ago and still this is > listed. > > The overall stats are > > Slot PID Stopping Connections Threads Async connections > total accepting busy idle writing keep-alive closing > 0 69336 no 1 yes 1 24 0 0 0 > 1 69338 no 0 yes 0 25 0 0 0 > Sum 2 0 1 1 49 0 0 0 > > which means only the connection who reads server-status is active. But I also > see listings as in: > > Srv PID Acc M CPU SS Req Dur Conn Child Slot Client Protocol > VHost Request > ... > 1-1 69338 0/0/10 _ 0.00 948 0 5 0.0 0.00 0.04 195.133.18.60 http/1.1 > domain.com:80 GET /up.php HTTP/1.1 > > The "SS" of 948 keeps on climbing, but the connection is long gone. How is > one supposed to read that? Is that a side effect of an MPM event change that > switches slots on re-activation? > > Any help appreciated. > > Cheers, > Stefan >
