#20 Write stats collecting mechanism

Geschlossen
vor 4 Jahren von yannweb geöffnet · 2 Kommentare
yannweb hat vor 4 Jahren kommentiert

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 ?

__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
yannweb hat das
enhancement
-Label vor 4 Jahren hinzugefügt
yannweb hat das
_core
-Label vor 4 Jahren hinzugefügt
yannweb hat vor 4 Jahren kommentiert
Besitzer

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
yannweb hat vor 4 Jahren eine neue Abhängigkeit hinzugefügt
yannweb hat die Zeiterfassung vor 4 Jahren gestartet
yannweb hat die Zeiterfassung vor 4 Jahren angehalten
31min 16s
yannweb hat vor 4 Jahren kommentiert
Besitzer

closed by b3af92459e

closed by b3af92459e
yannweb hat vor 4 Jahren geschlossen
Anmelden, um an der Diskussion teilzunehmen.
Kein Meilenstein
Niemand zuständig
1 Beteiligte
Aufgewendete Zeit: 5h 37min 52s
Yann Weber
5h 37min 52s
Fällig am

Kein Fälligkeitsdatum gesetzt.

Laden…
Abbrechen
Speichern
Hier gibt es bis jetzt noch keinen Inhalt.