Open roji opened 4 years ago
Is this still a problem @roji?
Current results:
| Total Bytes Written | 7,628,760 | ▃▆▇▇██████▄ |
| Total Bytes Read | 194,513,114 | ▃▆▇▇██████▄ |
| Max Command Rate | 0 | |
| Total Commands | 0 | |
| Max Active Commands per second | -79,020 | |
| Total Failed Commands | 0 | |
| Max Prepared Commands Ratio | NaN | |
| Max Connection Pools | 1 | ████████████ |
| Max Idle Connections | 18 | ▅▁ ▁ ▁ ▂██ |
| Max Busy Connections | 18 | ▅▇█▇██▇██▆ |
| Max Average commands per multiplexing batch per second | 16 | █▇▇▆▆▅▅▅▅▅▅▅ |
| Max Average write time per multiplexing batch (us) per second | 0 | |
OK so still broken it seems based on the negative number being reported. Could it be an overflow issue in that one counter?
This is most probably an issue in Npgsql itself... Which BTW there's a strong chance we'll rewrite to use the newer OpenTelemetry metrics (https://github.com/npgsql/npgsql/issues/3960, there's even the start of semantic standardization going on).
I don't know what the status is of collecting runtime/kestrel metrics via OpenTeletry, but we may want to implement capturing support in crank...
As long as the metrics can be egressed via EventSource
they can be captured easily out-of-proc via the .NET diagnostics server (EventPipe).
Not sure yet if it's in Npgsql itself or in the benchmark infra, but: