Sto scrivendo un server multithread che sostanzialmente sia una
versione light weight delle Session di Java (o almeno così mi hanno
detto).
Avrei un thread che accetta le richieste contenenti una Session ID, le
mette su una coda e dei thread che leggono la coda, usano un DB,
scrivono dei files, rispondono via socket e riempiono una coda di
cleanup, un altro thread si occupa di liberare la memoria della coda
di lavori.
Potrei creare un numero costante di thread e finirla li.
Probabilmente otterrei un funzionamento più interessante se il numero
di thread fosse variabile a seconda del carico/risorse disponibili.
Senza entrare troppo nei "system internals" c'è qualche scritto,
indizio, considerazione che possa illuminarmi su che strategie
adottare per la creazione/riduzione dinamica dei thread?
eg:
- i thread devono essere lunghezza della coda N/K
- se la coda aumenta di N nell'intervallo di tempo t aggiungi N/K
thread
- varie...
Ovvio che dato numero di thread > numero processori mi aspetto che
l'efficienza degradi all'aumentare dei thread ma riesca a mantenere
accettabile il tempo per soddisfare le nuove richieste.
Ragionando a "voce alta" potrei fissare un po' di "baleddi":
- supposto di conoscere il tempo medio per rispondere a una richiesta
quando se ne stanno servendo già N potrei limitare l'aumentare del
numero di thread a quel numero che rende "accettabili" le attese e
lasciare un thread libero per rispondere immediatamente "server is too
busy".
- questo tempo a parte la crescita dovuta allo overhead di maggior
time slicing potrebbe avere un comportamento molto più brusco quando
mi avvicino all'esaurimento di qualche risorsa
- se voglio aumentare il numero di thread non lo faccio
uno alla volta
- se lo aumento vorrei farlo di un numero tale che mi eviti di
riaumentarlo immediatamente dopo.
- il costo di chiamare pthread_create cambia se fatto a raffica o one
shot?
- bisognerebbe conoscere R(t) qualitativamente (Richieste, tempo)
- varie...
- bisognerebbe sapere se vale la pena sbattersi...
Dato per buono che sono sempre a tempo ad accontentarmi di qualche
cosa che funzioni, che l'algoritmo di gestione della coda posso
sostituirlo più tardi e che ho altre parti del programma da sistemare
solo per renderlo utile prima ancora che renderlo efficiente...
Qualcuno ha commenti formativi da fare oltre a "ritorna a zappare
l'orto"?
|