Un ambiente nuovo per ogni richiesta?
Monday, 02 July 07
Alle prime esperienze con la creazione di applicazioni in Ruby, cercando informazioni sulle problematiche generate dal fatto che mod_ruby usa lo stesso interprete per ogni processo Apache tra diverse richieste
mi sono imbattuto in questo articolo.
L'idea dell'autore e' che non avere un ambiente fresco ad ogni richiesta e' un limite serio alla affidabilita' della applicazione se assumiamo come costante il tempo di debugging impiegato durante lo sviluppo.
Io sono d'accordo e credo davvero che Ruby dovrebbe seguire il modello di PHP, che riesce ad avere performance decenti anche senza condividere gli interpreti tra diverse sessioni.
Con la condivisione tutto cio' che sta nelle variabili globali (o nelle variabili di classe) e' un potenziale leak, cosi' come ogni file aperto, e bisogna ogni volta chiedersi se al momento della finalizzazione qualcuno liberera' le nostre risorse come speriamo anche quando non ci sono leak che coinvolgono variabili globali o di classe.
Un ambiente nuovo per ogni richiesta? Io penso che sia la giusta strada.
Quando serve condividere lo stato, per finalita' di caching o altro, tra diverse sessioni, ci sono soluzioni sane come memcached e molte altre.
L'idea dell'autore e' che non avere un ambiente fresco ad ogni richiesta e' un limite serio alla affidabilita' della applicazione se assumiamo come costante il tempo di debugging impiegato durante lo sviluppo.
Io sono d'accordo e credo davvero che Ruby dovrebbe seguire il modello di PHP, che riesce ad avere performance decenti anche senza condividere gli interpreti tra diverse sessioni.
Con la condivisione tutto cio' che sta nelle variabili globali (o nelle variabili di classe) e' un potenziale leak, cosi' come ogni file aperto, e bisogna ogni volta chiedersi se al momento della finalizzazione qualcuno liberera' le nostre risorse come speriamo anche quando non ci sono leak che coinvolgono variabili globali o di classe.
Un ambiente nuovo per ogni richiesta? Io penso che sia la giusta strada.
Quando serve condividere lo stato, per finalita' di caching o altro, tra diverse sessioni, ci sono soluzioni sane come memcached e molte altre.
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.
Note: you'll not see this box again if you are a usual reader.
Tuttavia, ho sempre trovato limitante, di php (ma forse è più corretto parlare di apache) la mancaza di una conservazione di stato tra due diverse chiamate, cosa che rende di fatto impossibile lavorare in maniera *seria* con un db (es.: ti mostro 10 righe, mi chiedi di modificarne una, abilito un lock-write, e attendo la tua modifica, quindi commit e rilascio).
Pensare di doverlo fare lato applicativo mi fa venire l'orticaria :-)
P.S:
"Nota: se sei un lettore abituale non vedrai più questo messaggio"
Pignoleria perché la vedo se sono iscritto ai feed? risposta perché la pagina è statica e tu non puoi sapere chi sono io, però...