[Gfoss] presentazione e nota su una email ricevuta dal PCN

Francesco P. Lovergine frankie a debian.org
Ven 10 Ott 2008 11:46:01 CEST


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


Maggiori informazioni sulla lista Gfoss