EGoverment - Decreto Flussi via web
ho inserito la seguente questione in un forum di informatica, tuttavia la riporto anche qui in quanto mi interesserebbe avere anche un parere più "matematico".
P.S spostate pure se pensate che il thread sia più di tipo "generale"
Se qualcuno di voi ha "seguito" le vicende del decreto flussi del 2007 (avrà sicuramente notato che da quest'anno la procedura di invio della domanda è stata traferita, seppur parzialmente, via web. Il ministero degli interni ha creato questo programmino java che, sulla base dei valori inseriti nelle textbox dell'applicazione, compila in automatico la domanda in formato pdf che successivamente viene inviata via mail.
La questione di mio interesse nasce all'invio, ovvero il numero max di domande che il ministero avrebbe accettato era, se non sbaglio, di 200.000 : all'apertura dei flussi (h 8.00 dello scorso sabato) si è scatenata la gara al "dito più veloce" (cito testualmente i commenti della stampa).
Ero interessato a capire come questo processo fosse stato gestito - io ho ipotizzato che alla ricezione dei click, il server annotasse l'ora (...millesimo di secondo!) e gestisse una lista dinamica facendo inviare di volta in volta le email (..sempre che si tratti di email) ai vari client in ragione dell'ordinamento temporale.
Volevo sapere se qualcuno ha una idea un attimo più chiara, facendo anche considerazioni sul traffico dei dati e la complessità computazionale della procedura.
Marvin
P.S spostate pure se pensate che il thread sia più di tipo "generale"
Se qualcuno di voi ha "seguito" le vicende del decreto flussi del 2007 (avrà sicuramente notato che da quest'anno la procedura di invio della domanda è stata traferita, seppur parzialmente, via web. Il ministero degli interni ha creato questo programmino java che, sulla base dei valori inseriti nelle textbox dell'applicazione, compila in automatico la domanda in formato pdf che successivamente viene inviata via mail.
La questione di mio interesse nasce all'invio, ovvero il numero max di domande che il ministero avrebbe accettato era, se non sbaglio, di 200.000 : all'apertura dei flussi (h 8.00 dello scorso sabato) si è scatenata la gara al "dito più veloce" (cito testualmente i commenti della stampa).
Ero interessato a capire come questo processo fosse stato gestito - io ho ipotizzato che alla ricezione dei click, il server annotasse l'ora (...millesimo di secondo!) e gestisse una lista dinamica facendo inviare di volta in volta le email (..sempre che si tratti di email) ai vari client in ragione dell'ordinamento temporale.
Volevo sapere se qualcuno ha una idea un attimo più chiara, facendo anche considerazioni sul traffico dei dati e la complessità computazionale della procedura.
Marvin
Risposte
Chiaramente annotare un'ora di arrivo che dipende in maniera molto sensibile dal livello di congestione della rete, dalle scelte del sistema operativo (che chiaramente processa solo un tot. di thread alla volta...), è una cosa assurda, inutile e dannosa, visto che ha anche portato al quasi collasso del sistema... per non parlare della totale ingiustizia che questo sistema crea.
A livello di gestione in memoria dei dati, di solito, le applicazioni web aprono un thread per ogni client, quindi non c'è una lista dinamica di domande, ma ogni thread memorizza i propri dati e agisce indipendentemente dagli altri. Questo si fa per problemi di sicurezza e, soprattutto, di scalabilità: di solito sono applicazioni che vengono eseguite su reti di server (anche molto grandi) (si pensi ai migliaia di server che ha google...) e, chiaramente, quando si ha a che fare con una configurazione tipo cluster fare delle liste puntate non ha molto senso, dato che l'idea stessa di passare un puntatore, contenente un indirizzo di memoria, perde di significato, quando i dati sono memorizzati su macchine diverse...
Poi non so se veramente il sistema usasse le email in pdf per inviare le domande (cosa a dir poco perversa...), ma la cosa più sensata, secondo me, sarebbe stata fare una connessione a un database con un modello a 3 strati: una volta ricevuta la domanda la si memorizza in un database relazionale, posto su un'altra macchina o su un'altro cluster di macchine... anche qui ci sono un po' di problemi sul fatto che ogni thread deve aspettare il suo turno per poter scrivere nel database, rendendo assurda l'idea di memorizzare l'ora...
A livello di gestione in memoria dei dati, di solito, le applicazioni web aprono un thread per ogni client, quindi non c'è una lista dinamica di domande, ma ogni thread memorizza i propri dati e agisce indipendentemente dagli altri. Questo si fa per problemi di sicurezza e, soprattutto, di scalabilità: di solito sono applicazioni che vengono eseguite su reti di server (anche molto grandi) (si pensi ai migliaia di server che ha google...) e, chiaramente, quando si ha a che fare con una configurazione tipo cluster fare delle liste puntate non ha molto senso, dato che l'idea stessa di passare un puntatore, contenente un indirizzo di memoria, perde di significato, quando i dati sono memorizzati su macchine diverse...
Poi non so se veramente il sistema usasse le email in pdf per inviare le domande (cosa a dir poco perversa...), ma la cosa più sensata, secondo me, sarebbe stata fare una connessione a un database con un modello a 3 strati: una volta ricevuta la domanda la si memorizza in un database relazionale, posto su un'altra macchina o su un'altro cluster di macchine... anche qui ci sono un po' di problemi sul fatto che ogni thread deve aspettare il suo turno per poter scrivere nel database, rendendo assurda l'idea di memorizzare l'ora...
Ciao David, nel tuo post hai toccato una serie di questioni.
Allora, sicuramente l'ora (...il secondo) era la variabile secondo la quale venivano strutturate le code, in quanto sull'email di notifica
veniva riportata l'ora di ricezione della documentazione online AL MILLESIMO DI SECONDO. Quindi, indicativamente, l'idea generale era
proprio quella, accetto tutto finchè non arrivo al livello soglia di domanda.
Il problema della scalabilità e della congestione è sicuramente il tema che mi stava più a cuore trattare - mi interessava capire, in maniera generale, per esempio quante "code" sono state create per processare tutte le pratiche...
Allora, sicuramente l'ora (...il secondo) era la variabile secondo la quale venivano strutturate le code, in quanto sull'email di notifica
veniva riportata l'ora di ricezione della documentazione online AL MILLESIMO DI SECONDO. Quindi, indicativamente, l'idea generale era
proprio quella, accetto tutto finchè non arrivo al livello soglia di domanda.
Il problema della scalabilità e della congestione è sicuramente il tema che mi stava più a cuore trattare - mi interessava capire, in maniera generale, per esempio quante "code" sono state create per processare tutte le pratiche...
Beh l'ora al millesimo di secondo è ovviamente altamente inutile quando poi il sistema ha ritardi ed è a un livello di congestione tale da necessitare anche un'ora per processare una richiesta, come si è letto in giro. Chiaramente è come mettere un'ora a caso, visto che comunque il livello di aleatorietà è tale da inficiare completamente quell'ora: è un'ora che dice solamente in quale istante il computer centrale ha processato una certa istruzione nel codice in esecuzione, ma è abbastanza scorrelata dal tempo in cui è stata fatta la richiesta...
Sul numero di richieste ricevute e sui criteri per compilarle non sono molto informato...
L'unica cosa che mi limito a far notare è la grave ingiustizia che produce un sistema concepito in maniera così, a mio modo di vedere, perversa.
Sul numero di richieste ricevute e sui criteri per compilarle non sono molto informato...
L'unica cosa che mi limito a far notare è la grave ingiustizia che produce un sistema concepito in maniera così, a mio modo di vedere, perversa.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo