On Fri, Oct 10, 2008 at 11:02:08AM +0200, Andrea Peri wrote: > >PING www.pcn.minambiente.it (62.152.115.215) 56(84) bytes of data. > >64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.3 ms > >64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.4 ms (DUP!) > >64 bytes from 62.152.115.215: icmp_seq=1 ttl=119 time=11.6 ms (DUP!) > >[...] > > > >Pensare poi di valutare le prestazioni di un web service a forza > >di ping ritengo qualifichi completamente chi gestisce il suddetto > >servizio. E non aggiungo altro. > > La performance di un servizio GIS online e' composta di vari elementi. > certamente uno dei piu' rilevanti e' il tempo di produzione della mappa. > > pero' in certe realta' non va ignorato i tempi di trasferimento della > mappa dal server di produzione verso il client in ascolto. > > La ragione per cui chiedono l'informazione del ping e' per stimare (a > spanna) tali tempi. > > Infatti se la banda con cui uno accede al portale e' bassa, il tempo > per ricevere una mappa da 100Kbyte sara' superiore al tempo che viene > impiegato da chi vi accede tramite una ADSL a banda elevata. > > certamente il metodo del ping e' di per se' poco efficiente. > perche' il percorso del ping e' senz'altro differente rispetto a > quello di una risposta HTTP. > Pero' una indicazione di massima la da'. >
Qui andiamo decisamente OT: Diciamo pure che mi aspetto che icmp e tcp abbiano queuing differente, compreso dropping di icmp rispetto a tcp all'occorrenza quando si fa shaping della banda - e tcp fra l'altro ha congestion control, mentre icmp no. Il risultato netto e' che usare icmp per valutazioni spannometriche e' fuorviante nella maggior parte dei casi. Avessero detto: andate all'url X e scaricate il file Y via http, sarebbe stato piu' corretto per una valutazione del tipo che serve a loro. Comunque transit, A lume di naso se una feature offre ECW e una navigazione e zomming rapidi su grosse moli di dati. Pensare che tiling e caching di sistemi alternativi sia ugualmente efficace mi pare ottimistico. Ci credo che so' lenti :-) Se poi aggiungiamo che mapserver secondo molti offre un 30% di prestazioni in piu' rispetto a ArcIMS . > Io caso mai farei notare una altra questione. > > nella lettera del PCN viene detto che la banda disponibile e' di 100 MB/s > > ma non e' chiaro se tale valore e' il livello di picco o la banda garantita. > La differenza non e' banale. > 100 MB/s garantiti in upload (per loro e' upload) costano tantissimo. > > 100MB/s con soli 8 MB/s garantiti costano molto meno. > Sono 100Mb/sec aggregati, come e' normale che sia. E notare il 'b' e non 'B' :) Quindi l'equivalente di una normale fastethernet. Considerato che non e' assolutamente un valore da rete geografica (2-4-8-16Mb, 34Mb, 155Mb, 2.5Gb e multipli sono valori credibili) direi che si riferiscono puramente alla velocita' della porta vlan assegnata al server, non alla banda di connessione. SE il loro backbone ha disponibilita' ben superiore a quei valori, FORSE si saturano quei 100Mb :-) Dipende pure dal traffico complessivo. Come confronto: http://www.garr.it/reteGARR/velocita.php?idmenu=rete ma non so in RUPA come stanno messi. -- Francesco P. Lovergine _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
