Newsgroup: it.lavoro.informatica
Titolo: Problemi tecnici alla compilazione online del censimento

Su alcuni problemi tecnici alla compilazione online del censimento,
inoltro un commento letto su NoiseFromAmerika (http://
www.noisefromamerika.org/index.php?module=comments&func=display&cid=78990&objectid=1548&modid=151&itemtype=1&thread=1#d78990
):
"Il censimento (che non gira) al tempo della patonza (che invece gira
eccome anche in trasferta)
In questo paese non funziona proprio nulla.
Ho iniziato alle 9 a cercare di compilare il censimento on-line:
usciva sempre un warning che diceva che sarebbe iniziato alle 9.
Ho sospettato che I.E. non funzionasse e alle 9.15 ho provato con
Firefox: funzionava!!!
per il login è chiesta una password di 14 caratteri ( con 22 milioni
di famiglie 8 caratteri )
inizio la compilazione: finito un foglio cerco di andare al
successivo: il sistema mi sbatte fuori, devo rilogginarmi e rifare il
foglio: mediamente succede ameno tre volte per foglio prima di potere
proseguire. Per fortuna quando si è sbattuti fuori al foglio n-esimo
il sistema memorizza i fogli precedenti; prima di proseguire, per
cecare di memorizzare anche l'ultimo foglio compilato, ho usato un
tasto "salva" ma non funziona. I fogli individuali come prima cosa
richiedono i dati personali già immessi nel primo foglio (persone
della famiglia) In due ore non ho potuto nemmeno compilare metà dei
questionari.
Ho telefonato al numero verde e dopo 21 minuti di musica funebre ho
potuto dire a uno sfigato precario che era una vergogna: lo sapeva già
(e sapeva anche che con I.E. non girava ma mettere un warning no) e mi
ha detto che i tecnici stavano lavorando.
Spero che ISTAT non faccia le statistiche con queste risorse
informatiche: spero di no. Per il censimento avranno incaricato la
solita società esterna ammanicata tanto costosa quanto inefficiente.
Sarei curioso di sapere quanto è costato Istat, quindi a noi, il
software per la compilazione on line del Censimento.
La patonza deve girare, l'importante è che la patonza giri per il
resto c'è sempre Mastercard."
--
ale
http://ale.riolo.co.uk

 inoltro un commento letto su NoiseFromAmerika (
http://www.noisefromamerika.org/index.php?module=comments&func=display&cid=7.
..
 
O anche 
http://groups.google.com/group/it.media.tv/browse_frm/thread/011e2aa8c358b8e2#
 
su IMtv.
 
--
ale
http://ale.riolo.co.uk
 
 


http://www.ansa.it/web/notizie/rubriche/topnews/2011/10/09/visualizza_new.html_674235404.html
Staranno lavorando sulla scalabilit�, si vede che non pensavano che 
l'avrebbero usato sul serio online... :-)


www.noisefromamerika.org/index.php?module=comments&func=display&cid=78990&objectid=1548&modid=151&itemtype=1&thread=1#d78990
):
Oltre al danno la beffa: :)
Da noisefromamerika:
"Messaggio di errore
User Error
BAD_PARAM
/home/c1002/www/noisefromamerika/
noisefromamerika.org/html/modules/comments/xaruserapi/get_one.php
(21): Argomenti mancanti o non valiti [cid] per userapi, nella
funzione get_one del modulo comments"
-- 
Living in Barbaropoli
http://www.barbaropoli.com

<<inizio la compilazione: finito un foglio cerco di andare al
inizia allora a capire (se ci arrivi)che c'erano 500.000 collegamenti al 
database.



Inizia a capire (se ci arrivi), che dovevano aspettarselo.
Ma chi ha fatto l'analisi ? Topo Gigio ?
PaF

Sapete mica che tecnologia � stata usata per il sito? Application Server, 
Web Server, Database, hardware e software di base?
Grazie.

 Ma chi ha fatto l'analisi ? Topo Gigio ?
Gli asset sono non cacheabili, non c'è nessun meccanismo di admission, 
eccetera eccetera....
500 kconnessioni potevano anche evitarle o averle su server di asset statici 
molto scalabili o... una CDN... (bestemmia!!!).
Il problema è che quando l'incompetenza è diffusa non c'è nessun feedback:
Un idiota progetta un sistema che viene realizzato da idioti, validato da 
idioti, testato da idioti, approvato ad idioti, venduto ad idioti... poi 
quando arriva alla fine qualcuno fa notare che c'è un problema... e 
ovviamente il feedback arriva a chi? A degli idioti :)
Altrimenti perché avremmo quell'aborto dell'olo2olo? Della PEC? Eccetera...
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213

 Inizia a capire (se ci arrivi), che dovevano aspettarselo.
iniziamo a capire che � una scemenza.
con 500.000 connessioni al database una applicazione web ci fa il 
censimento di tutto l'universo.


Fatto alla vecchia maniera in ascii dove non si sprecava un bit un 
fascicolo di censimento saranno ad andare grassa 2Kb forse 4, mettiamo 
che abbiano usato xml e moltiplichiamo per 25 fanno 100K * 22M = 2200M * 
k= 2.2Tb (circa)
22M di transazioni da 100K (che sono solo delle insert) un db nel 2011 
se le deve mangiare all istante (1Tb di ram ecc costa circa 25000 euro 
estrapolando il costo per GB).

 estrapolando il costo per GB).
 
La situazione è ancora migliore, da nessuna parte c'è scritto che il sistema 
debba mettere in sincrono tutti i dati in un unico database.
 
Ogni server "dati" puoi tranquillamente storare localmente e mandare ad un 
db centrale solo quando serve.
 
 
Ma qui si sta parlando di gente che ha fatto un sistema con JS e CSS non 
minificati (ci sono i commenti) in diversi file separati (25 richieste HTTP 
per pagina) e fino a poco fa NON CACHEABILI.
 
Qui non ce la facevano neanche a servire i contenuti statici....
 
Ciao,


Separerei il problema in due parti:
- dimensionamento
- gestione del supero valori dimensionamento
Se dovessimo disegnare un sistema che possa reggere senza sforzo un 
valore di picco enorme rispetto al valore medio degli accessi saremmo 
costretti a spendere una superiore di denaro (e li avremmo criticati per 
questo!!!). Qui abbiamo 3 mesi per rispondere e possiamo scaglionarci 
nel tempo, diverso il discorso dei click-day....
Quindi da parte mia nessuna critica sul dimensionamento, anche perch� ho 
letto commenti di persone che nel pomeriggio sono riusciti a copletare 
l'inserimento in pochi minuti....
Sul secondo punto concentrerei la mia attenzione: possibile che non si 
poteva mettere davanti un "concentratore" (load-balancer  lan o 
applicativo) che potesse servire da front-end, accettare N-mila 
connessioni e dirottare tutte le altre su una pagina statica con un 
chiaro messaggio "N-mila utenti stanno gi� riempiendo il questionario 
online, si prega di riprovare pi� tardi".
Qualcuno si sarebbe comunque lamentato di non aver potuto fare 
l'inserimento ma non avremmo avuto le odiose disconnessioni, avremmo 
dato una immagine di efficienza e che l'afflusso straordinario era stato 
previsto con appositi strumenti di gestione degli accessi....
Tecnicamente: il codice html sembra buono, buono l'uso dei css, buono 
l'uso dell'e-tag. Manca l'expire, manca l'uso di una cdn per le 
immagini, css e .js e quest'ultimi non sono riuniti in un solo file per 
avere meno accessi ma sono finezze che non so nemmeno quanto possano 
essere apprezzabili in un uso normale...

 essere apprezzabili in un uso normale...
PS: ho analizzato solo l'home page...

 - dimensionamento
Io spero che nel 2011 esista una modalita' per affittare risorse temporaneamente e quindi gestire anche un sovradimensionamento
esagerato senza spendere l'impossibile (non parlo del cloud specificatamente)..............
Giulia



eh dipende da come � scritto il software...
Ma a parte il numero, fossero anche 50 connessioni, il fatto che sia
crollato tutto al primo giorno cosa ti fa pensare ? Ad un lavoro
professionale ?
PaF

specificatamente)..............
Bastava chiedere ad Amazon....

 debba mettere in sincrono tutti i dati in un unico database.
premesso che non ho numeri sottomano e non so nemmeno che tecnologie 
usano, però tipicamente in questi casi il database è l'ultimo ad andare 
in crisi, a meno che non ci siano errori grossolani ma a quel punto è 
molto più facile sbagliare lato application server e/o web. anche perché 
su quel fronte gli errori sono molto comuni e la competenza scarseggia 
(e comunque c'è la tendenza a sbattere il muso sul problema).
tempo fa su una infrastruttura bilanciata su due nodi una applicazione 
stupidissima la mandava in crisi per poco più di cento utenti, per farla 
breve la "colpa" era dei contenuti statici (immagini delle pagine, css, 
js, e quant'altro) serviti dagli as ed è stato sufficiente copiare 
questi contenuti sul webserver e mettere una regolina di rewrite su 
apache perché da una infrastruttura in crisi si passasse ad una 
infrastruttura che lavora in leggerezza.

 professionale ?
no non sto dicendo questo. dico semmai che non penso sia stato il 
database a cedere. diciamo che l'impatto del sovraccarico prima lo deve 
superare il load balancer, poi l'application server e infine il 
database; di solito il problema si ferma prima.

 essere apprezzabili in un uso normale...
Non sono per nulla finezze, sono cose che ti diminuiscono di un fattore 10 
il carico sui server e sulla rete!
Sono finezze per applicazioni con basso carico


 Su alcuni problemi tecnici alla compilazione online del censimento,
 
Io saro' pessismista di natura sul connubbio IT e PA italiana ma manco
ci ho provato.
Ho compilato i miei bei fogli e stamattina li ho lasciati in posta
prima di venire in ufficio, il resto sono cazzi loro.
 
Ciao
   Francesco

 software per la compilazione on line del Censimento.
Tutta l'operazione (quindi non solo il portale) sembra sia costata 590 
milioni circa e 4 anni di lavoro.
330 circa per gli organi (comuni,regioni e provincie e ministero interno)
220 circa spesa corrente e acquisto servizi
8 circa spese conto capitale
30 circa per spese personale istat a tempo determinato

resto c'� sempre Mastercard."
il 29 Settembre mi ero illuso di poter trasferire la mia dichiarzione
dei redditi all'Agenzia delle Entrate, per via telematica...
usando il software GRATUITO dell'AdE,
come avevo gia' fatto l'hanno scorso.
Direte che non e' il caso di ridursi agli ultimi giorni, e va bene.
Tuttavia....pur avendo linea adsl ok, e pc perfettamente ok....
per la trasmissione mi ci sono volute ORE....
ripeto ORE.
E scarica la macchina Java, e scarica i prerequisiti per il sistema 
operativo,
 e scarica il software File Internet, e scarica i moduli di controllo
e controlla gli studi di settore, e controlla l'irap.
Parte del software e' solo su internet, parta scarica comunque
degli oggetti sul pc, altra parte e' da installare in maniera tradizionale
ovvero download + installazione.
Alla fine ce l'ho fatta, ma la mia impressione  generale e' quella di una
serie di pacchetti, moduli, programmi ...nati slegati fra loro e  malamente 
raffazzonati.
Notare anche che gli ultimi aggiornamenti sono in data 22 settembre,
con il 30 come scadenza ultima.
Che poi  scadenza ultima non e', perche' con 25
euro ti danno altri 90 giorni...
Ciliegina sulla torta:  il numero verde dell'Agenzia delle Entrate nel 
giorno 29, assistenza
tecnica ,  era  occupato fisso...dalle 10 alle 16 ...  e quindi supporto 
ZERO.
Bella Italia, amate sponde
ciao
fm

 Web Server, Database, hardware e software di base?
Già. Tra HTML, CSS, Javascript, strati di framework frammisti a crema
pasticcera si saranno persi miliardi di cicli elaborativi, che
potevano gestire altre decine di migliaia di utenti con gli stessi
identici server. Ma vuoi mettere barrare celibe/coniugato con le
lucine che si accendono? :-))


Se le lucine si accendono sprechi cicli elaborativi sul client non sul 
server pero' :)
Quale soluzione tecnica avresti adottato per poter erogare un servizio 
che necessit� di raggiungere il maggior numero possibile di utenti a 
costi contenuti  come quello del censimento in alternativa?


che seppure con altre parole e' la stessa risposta che ti ho dato 
nell'altro ng :-D
-- 
Oni wa soto! Fuku wa uchi!


Ok, allora siamo d'accordo... :-)

 costi contenuti  come quello del censimento in alternativa?
Sarai d'accordo che massimizzare il numero di utenti gestibili da un
singolo server è certamente un obiettivo assolutamente primario in una
procedura come questa.  Se può essere utile unificare i files Html,
CSS, JS, ecc., e comprimerli, come dha detto giustamente qualcuno,
figuriamoci se non è utile eliminarne proprio qualcuno, ridurre allo
stretto necessario il contenuto di altri, o alleggerire la produzione
di tali files sul server eliminando qualche elaborazione intermedia
(puoi leggere: generazione pagine ad hoc invece che tramite
framework).

 figuriamoci se non è utile eliminarne proprio qualcuno,
Relativamente inutile quando la tua applicazione serve UN file js 
cacheabile, UN file css cacheabile e qualche immagine (e anche quelle si 
possono riunire in un unico file).
Quello che è assolutamente da tener sotto controllo sono le richieste http 
rest in corso d'opera che vanno limitate al più a una per form (anche se il 
local storage potrebbe evitare pure quelle).


 possono riunire in un unico file).
 
Relativamente non significa totalmente. Quando sei con le risorse
limitate, cioè sempre, certe domande te le devi porre. Poi l'efficacia
del cacheable dipende anche dalle impostazioni locali del browser,
giusto? E possiamo affidarci alle impostazioni del client per
progettare una applicazione del genere?
Se ragioniamo come dici tu, abbiamo visto cosa succede. Poi non ci
lamentiamo.



avranno chiesto a un suocero o un cugino... -_-'
 

 lamentiamo.
 
Io invece sostengo che sia esattamente il contrario. È a causa di quelli che 
per risolvere un problema architetturale tolgono le "lucine" e non pensano 
ai problemi più importanti che vien fuori il patatrac....
 
Quindi, formula la tua proposta, l'applicazione l'hai vista, quali sono gli 
interventi più importanti per farla scalare? Oltre alle lucine... ?



ma che razza di discorsi...
se vuoi che il cittadino se lo passi da se devi dargli una interfaccia
accessibile, intuitiva e funzionale, altrimenti stabilisci che il
cittadino compila solo sulla carta e l'impiegato addetto lo istruisci
a inserirlo con l'interfaccia che ti pare.
 

 interventi più importanti per farla scalare? Oltre alle lucine... ?
Ho dato un'occhiata alle prime due pagine del sito, in effetti sono
molto semplici, essenziali, ma chiare. Le lucine non ce l'hanno
messe :-)
Ma di sicuro  l'intervento che consiglierei non è comprare nuovi
server, come dici tu :-))

 server, come dici tu :-))
Allora non hai capito una fava. Io dico esattamente il contrario. 
Probabilmente com'è implementato ora l'hardware è decisamente 
sovradimensionato.



Sono d'accordo sul principio di semplificare i sistemi ma tu non stai 
dicendo ora di eliminare  le lucine  ma di ottimizzare il software che 
sta dietro alle lucine utilizzando dei framework piu' veloci e piu' 
ottimizzati per sfruttare appieno l'hardware che e' una cosa diversa 
dall'eliminare le lucine: le fai in un altro modo.
  L'interfaccia che renderizzi sul client a mio avviso  ha un peso 
relativo per quanto riguarda le prestazioni lato server se il software 
che la genera e' scritto decentemente.
Io personalemnte indagherei piu' sugli aspetti architetturali  invece di 
  partire dall'interfaccia.
Questa frase invece mi e' oscura: "generazione pagine ad hoc invece che 
tramite framework"

 nostri.
il problema è quello che consideri tu "lucine". hai citato javascript
e css, ma quelle non sono "lucine" ma elementi essenziali per
realizzare un sito accessibile e performante, ovvero usabile. visto
che stiamo parlando di un sito che dovrebbe essere usato il più
possibile da comuni cittadini sarebbero soldi buttati se non si
raggiungesse questo obiettivo per via della scarsa usabilità del sito.
secondo me dovresti aggiornare il tuo repository dei luoghi comuni,
javascript e css non sono più (ammesso che lo siano stati in passato)
inutili fardelli decorativi ma strumenti che hanno abituato ad una
"user experience" particolarmente diversa rispetto ai tempi a cui
vorresti riportare il web :)


Mmmmh, per tagliare il superfluo in questi ambiti devi essere mandrake! :-)
Oggi si va di server virtuali a manetta, la ram a manetta � moda passata... 
:-D
Seriamente, la complessit� aumenta, gli strati di mezzo pure, ergo, il 
controllo di fino sull'intero sistema non c'� proprio pi�.
Il lato positivo � che � un modo per dare lavoro a tanti e per far girare 
l'economia...

 sovradimensionato.
Qui ci stiamo azzuffando (si fa per dire), ma magari il problema è
nelle linee telefoniche. Chi lo sa.

 tramite framework"
l'hai tradotta bene con : "utilizzando dei framework piu' veloci e
piu' ottimizzati"

 vorresti riportare il web :)
"User experience" nella compilazione del modulo del censimento?  :-))
Ho visto che questo sito è molto scarno in quanto a grafica, ben poco
JS. Tu questo sito come lo giudichi?

 JS. Tu questo sito come lo giudichi?
"questo sito" quale?
e in ogni caso cosa c'entra la grafica con il javascript?

 nelle linee telefoniche. Chi lo sa.
Telefoniche? Semmai "linee dati" :)
È possibile anche se improbabile (e sarebbe un bello smacco per interbuso & 
Telecom), ma con gli accorgimenti che ho citato si riduce di un fattore 3-4 
anche il traffico in rete.
Ciao,



Proprio perche' si e' seduto al primo run (sotto carico) mi fa supporre 
che piu' che le lucine potrebbe essere l'architettura non corretta il 
problema. Non sto dicendo cosa deve essere fatto per risolvere la 
situazione attuale ma dove potrebbe essere localizzata la radice del 
problema;  In sostanza non concordo sul fatto che se ti privi 
dell'interfaccia e la rendi piu' spartana risolvi il problema che il 
sistema sotto carico non funzioni piu' correttamente.