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
додав(ла) до BETA version етапу 4 роки тому
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>
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
Something is not working duplicate
This issue or pull request already exists enhancement
New feature help wanted
Need some help invalid
Something is wrong question
More information is needed Tests
Tests using check or unittests wontfix
This won't be fixed _core
About PyFCGI internal components _deployment _libpyfcgi
About PyFCGI Python components
Термін виконання не встановлений.
Видалення гілки НЕЗВОРОТНЕ. Дію не можна скасувати. Продовжити?