Find a way to collect stats in pool_handling process.
The collection mechanism should give access to UDP server ( see #19 ) to following data :
worker count
requests count last 10/5/1 minute
request time average (maybe ?) => slow IPC between worker & pool ?
total request counter (maybe ?) => will overflow ?!
idle/busy state (maybe ?) => change too fast ?
idle/busy ratio or workload (maybe ?)
We have to take care of not slowing down the workers with this component…
Maybe the collection child could help implementing this mechanism ?
__Nedd #24__
Find a way to collect stats in pool_handling process.
The collection mechanism should give access to UDP server ( see #19 ) to following data :
- worker count
- requests count last 10/5/1 minute
- request time average (maybe ?) => slow IPC between worker & pool ?
- total request counter (maybe ?) => will overflow ?!
- idle/busy state (maybe ?) => change too fast ?
- idle/busy ratio or workload (maybe ?)
We have to take care of not slowing down the workers with this component...
Maybe the collection child could help implementing this mechanism ?
yannweb
hat diesen Issue vor 4 Jahren zum BETA version Meilenstein hinzugefügt
A solution to a fast request counter implementation can use semaphores :
When a worker starts handling a request it increment a sempahore. Meanwhile, a counter process (pool_handler or stats collection child) will attempt to decrease (fast enough) the semaphore with WNOHANG.
If the decrement semop do not fail, a counter can be incremented.
Note : the 10/5/1 min counters implies to store all requests timestamps ?? Maybe we can associate a timestamp with a request count ?
=> if 100 req/s stores {time(NULL), 100} and not time_t [100] = {time(NULL), time(NULL), etc.}
A solution to a fast request counter implementation can use semaphores :
When a worker starts handling a request it increment a sempahore. Meanwhile, a counter process (pool_handler or stats collection child) will attempt to decrease (fast enough) the semaphore with WNOHANG.
If the decrement semop do not fail, a counter can be incremented.
Note : the 10/5/1 min counters implies to store all requests timestamps ?? Maybe we can associate a timestamp with a request count ?
<code>=> if 100 req/s stores {time(NULL), 100} and not time_t [100] = {time(NULL), time(NULL), etc.}</code>
yannweb hat die Zeiterfassung vor 4 Jahren gestartet
yannweb hat die Zeiterfassung vor 4 Jahren angehalten
54min 36s
yannweb hat die Zeiterfassung vor 4 Jahren gestartet
yannweb hat die Zeiterfassung vor 4 Jahren angehalten
3h 12min
yannweb
hat sich das Issue vor 4 Jahren selbst zugewiesen
yannweb hat vor 4 Jahren gearbeitete Zeit hinzugefügt
1h
yannweb hat vor 4 Jahren eine neue Abhängigkeit hinzugefügt
Nedd #24
Find a way to collect stats in pool_handling process.
The collection mechanism should give access to UDP server ( see #19 ) to following data :
We have to take care of not slowing down the workers with this component…
Maybe the collection child could help implementing this mechanism ?
A solution to a fast request counter implementation can use semaphores :
When a worker starts handling a request it increment a sempahore. Meanwhile, a counter process (pool_handler or stats collection child) will attempt to decrease (fast enough) the semaphore with WNOHANG.
If the decrement semop do not fail, a counter can be incremented.
Note : the 10/5/1 min counters implies to store all requests timestamps ?? Maybe we can associate a timestamp with a request count ?
=> if 100 req/s stores {time(NULL), 100} and not time_t [100] = {time(NULL), time(NULL), etc.}
closed by b3af92459e