proxy: ustats internal refactor #1149
Conversation
|
this change prepares for a potential performance fix (at least benchmarking the effect of) of inlining the ustats names in the global struct vs using a pointer for each. If the However this needs to be proved and the code prepared for it since that change would use a little excess memory. |
|
eh. maybe it could "compile" the names down into a compact buffer during the reload stage. now that I have a separate structure for the config side vs the worker side that's pretty easy actually. 1024 stats would be over 130k of just name memory, which sucks if the names are much shorter than the limit (128 bytes). debating just doing this now... if I also unroll the snprintf it'll get a significant CPU boost. then people using billions of counters wouldn't be punching themselves in the face as hard. |
|
This is done now. I'll let it sit for a while then review it and merge to staging. Can see the difference in performance counters but it's pretty hard to test the impact of the performance fixes... If I ever care enough to quantify it I could see about raising the default stat count limit. |
If a ustat changes name for the same index, its value is reset to 0. Cleans up some confusing code around how ustats are handled; the global ctx and worker threads now use different structures with different intent, instead of different sides of the same struct. Speeds up `stats proxy` dumping by compacting stat names into a linear buffer, and unrolls some snprintf's into direct memory copies plus a faster itoa. Also reorders the entries in the global ctx so the most frequently accessed ones are clustered toward the front of the struct.
|
merged to staging. fixes a lot of longstanding annoyances. |
If a ustat changes name for the same index, its value is reset to 0.
Cleans up some confusing code around how ustats are handled; the global ctx and worker threads now use different structures with different intent, instead of different sides of the same struct.
Also reorders the entries in the global ctx so the most frequently accessed ones are clustered toward the front of the struct.