consiglio HARDWARE per sistema webgis

[Andrea Peri]

>l sistema è un classico del FOSS: openlayers, geoserver+geowebcache,postgis
>Il territorio da coprire è sui 100kmq, e precalcolo le tiles dalla scala 1:500 a 1:20000
>Il che equivale a circa 120mila tiles per livello sulla base di esperienzi simili che ho già fatto
>Purtroppo ho un server virtuale. Se non precalcolo le tile le performance sono non ottimali.
>Il calcolo delle tile impiega 24ore per livello sempre sulla base dell esperienza (e i livelli sono centinaia).
>
>Le ho provate tutte ma sono giunto alla conclusione che il server virtuale è davvero troppo lento, e quindi per far "volare" davvero un sistema ci vuole un server fisico.

Frmo restando che un hardware vero è sempre meglio.

NOn lo ho mai prove comparative di questo tipo, ma partendo dal fatto che geoserver ha uno strato java su cui si appoggia, mentre mapserver si appoggia direttamente sulla cpu (trattandosi di una CGI),
sarei portato a dire che su una macchina virtuale rende meglio mapserver di geoserver.

Inoltre io non userei meccanismi di cache, ma andrei a diritto.
Daccordo che è lento, ma quanto lento ?
E poi che dati devi distribuire ?

In generale secondo me i meccanismi di cache vanno bene per le ortofoto. Con i dati vettoriali non rendono un granche in termini qualitativi.
Tutto cio' che è vettoriale solitamente perde di qualita', alche' per mantenere la qualità grafica sei costretto a impostare la cache per recuperare sempre dal server wms (perdendo quindi i benefici di risposta).

Infine per rendere ottimale l'impiego di una cache, dovresti usarla su una differente macchina virtuale rispetto a quella dove gira il server wms.


Andrea.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[D_Guidi]

> Non lo ho mai prove comparative di questo tipo, ma partendo dal fatto che
> geoserver ha uno strato java su cui si appoggia, mentre mapserver si
> appoggia direttamente sulla cpu (trattandosi di una CGI),
> sarei portato a dire che su una macchina virtuale rende meglio mapserver
> di geoserver.
Onestamente, a quanto ne so, la macchina virtuale in un sistema
virtualizzato rende esattamente come su un sistema reale, nel senso
che la virtualizzazione lavora a bassissimo livello e la JVM vede un
processore in tutto e per tutto uguale ad uno fisico.
Semmai il discorso è che se, sottolineo se, mapserver è il 20% più
veloce di geoserver, non avendo il "collo di bottiglia" della JVM,
(non sto trollando, si fa per fare un esempio), in un sistema
virtualizzato che già è più lento di suo, l'ulteriore rallentamento si
potrebbe vedere maggiormente.
Detto questo io eviterei di escludere un sistema virtualizzato: il
mondo va da quella parte (amazon, azure, ecc) e probabilmente le cause
della lentezza eccessiva del sistema sono da altre parti... hai 100
layer? non sarai mai veloce IMHO, occorre pensare a delle
ottimizzazioni (tiles, dataset semplificati per scala di
visualizzazione, ecc).

> In generale secondo me i meccanismi di cache vanno bene per le ortofoto.
> Con i dati vettoriali non rendono un granche in termini qualitativi.
> Tutto cio' che è vettoriale solitamente perde di qualita', alche' per
> mantenere la qualità grafica sei costretto a impostare la cache per
> recuperare sempre dal server wms (perdendo quindi i benefici di risposta).
Non ho capito questo discorso, dalla mia limitata esperienza con le
tiles vai benone, purchè il tuo dataset sia "fisso" (ovvero hai il
controllo sul cambiamento dei dati) ovviamente. Se non sbaglio
geowebcache è in grado di invalidare le tiles se una parte del dataset
cambia.
IMHO il problema con le tiles è che se hai 100 layer, o "tilizzi"
tutti i layer (perdendo la possibilità di visualizzare/spegnere i
tematismi) o tilizzi ogni singolo layer (ma poi lato client scarichi
100 * N tiles, ovvero mega e mega di roba).
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Aime]

2012/10/24 Diego Guidi <[hidden email]>:

>> In generale secondo me i meccanismi di cache vanno bene per le ortofoto.
>> Con i dati vettoriali non rendono un granche in termini qualitativi.
>> Tutto cio' che è vettoriale solitamente perde di qualita', alche' per
>> mantenere la qualità grafica sei costretto a impostare la cache per
>> recuperare sempre dal server wms (perdendo quindi i benefici di risposta).
> Non ho capito questo discorso, dalla mia limitata esperienza con le
> tiles vai benone, purchè il tuo dataset sia "fisso" (ovvero hai il
> controllo sul cambiamento dei dati) ovviamente. Se non sbaglio
> geowebcache è in grado di invalidare le tiles se una parte del dataset
> cambia.

Si, lo fa o in risposta a un feed RSS che contiene le indicazioni delle
aree modificate, o in risposta a chiamate WFS-T, qualora GWC sia
integrata con GeoServer.

> IMHO il problema con le tiles è che se hai 100 layer, o "tilizzi"
> tutti i layer (perdendo la possibilità di visualizzare/spegnere i
> tematismi) o tilizzi ogni singolo layer (ma poi lato client scarichi
> 100 * N tiles, ovvero mega e mega di roba).

Ci sono anche soluzioni intermedie che GWC al momento non supporta,
ma per le quali stiamo cercando fondi: create le tile cache separate,
ma fare poi in modo che GWC possa rispondere a una richiesta
di N layer prendendo dalle varie cache e fondendo il risultato in una sola
tile: è un compromesso che aumenta la flessibilità a discapito di un maggiore
uso di CPU (più lento di una cache statica, ma pur sempre più veloce dell'uso
di un WMS diretto).

Btw, riguardo al discorso raster contro vettoriale: sperimentalmente abbiamo
visto un fattore di accelerazione 100 per mappe vettoriali cachate contro
un uso di un WMS diretto e mappe non banali,
mentre di solo 10 sui dati raster contro un WMS diretto e dati ben preparati
sul disco. Quel vantaggio di 10 si sta assottigliando
col tempo man mano che ottimizziamo la catena di servizio raster di GeoServer
(ad esempio, di recente abbiamo fatto modifiche che hanno quasi raddoppiato
le prestazioni nel caso di riproiezione raster sulla versione "trunk"
di GeoServer).

Ciao
Andrea

--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: [phone]
fax: [phone]
mob: [phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Alessandro Radaelli]

Il 25/10/2012 21:34, Andrea Aime ha scritto:
> Ci sono anche soluzioni intermedie che GWC al momento non supporta,
> ma per le quali stiamo cercando fondi: create le tile cache separate,
> ma fare poi in modo che GWC possa rispondere a una richiesta
> di N layer prendendo dalle varie cache e fondendo il risultato in una sola
> tile: è un compromesso che aumenta la flessibilità a discapito di un maggiore
> uso di CPU (più lento di una cache statica, ma pur sempre più veloce dell'uso
> di un WMS diretto).

Molto interessante, potremmo essere interessati a sponsorizzare questo
sviluppo in parte o totalmente (dipende dalla cifra...).
Ovviamente andrebbe più lento di una cache diretta, ma più veloce di un
WMS diretto. So che è difficile valutare, ma avete idea o qualche stima
di quanto più veloce potrebbe andare?
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Aime]

2012/10/26 Alessandro Radaelli <[hidden email]>:

> Il 25/10/2012 21:34, Andrea Aime ha scritto:
>> Ci sono anche soluzioni intermedie che GWC al momento non supporta,
>> ma per le quali stiamo cercando fondi: create le tile cache separate,
>> ma fare poi in modo che GWC possa rispondere a una richiesta
>> di N layer prendendo dalle varie cache e fondendo il risultato in una sola
>> tile: è un compromesso che aumenta la flessibilità a discapito di un maggiore
>> uso di CPU (più lento di una cache statica, ma pur sempre più veloce dell'uso
>> di un WMS diretto).
>
> Molto interessante, potremmo essere interessati a sponsorizzare questo
> sviluppo in parte o totalmente (dipende dalla cifra...).
> Ovviamente andrebbe più lento di una cache diretta, ma più veloce di un
> WMS diretto. So che è difficile valutare, ma avete idea o qualche stima
> di quanto più veloce potrebbe andare?

Hmm... no? :-)

Da un parte abbiamo un processo (WMS) che deve caricare i dati dalle
varie sorgenti, disegnarli, e comprimere il risultato in PNG/JPEG

Dall'altra parte abbiamo un process (WMTS) che deve prendere N tiles,
necessariamente in PNG (o eventualmente TIFF) visto che abbiamo bisogno
della traslucenza, combinarle in un'unica immagine, e produrre un file in
output, eventualmente applicando una quantizzazione al volo se si vuole
servire un PNG8.
La parte lenta qui è aprire le n PNG, in teoria uno potrebbe anche salvarsi
la cache in TIFF non compresso, che sarebbe velocissimo da aprire,
ma andrebbe ad occupare un visibilio in termini di spazio.

Long story short, se dobbiamo aprire tanti PNG per produrre la tile
(molti layer combinati) mentre dall'altra parte abbiamo che il WMS
deve caricare poco o nulla in termini di dati (perchè magari siamo
finiti in un'area vuota o con uno denominatore di scala troppo basso)
può anche essere che il WMS sia più veloce.

Il caso opposto sono tile dense di dati, e magari ne stiamo combinando
poche, in tal caso mi aspetto che il WMTS con la fusione delle
tiles sia significativamente più veloce (2-10 volte? abbi pietà,
sto dando i numeri qui, per sapere qualcosa di preciso ci
sarebbe da fare un piccolo benchmark).

Ciao
Andrea


> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 605 iscritti al 10.7.2012



--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: [phone]
fax: [phone]
mob: [phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[a.furieri]

On Fri, 26 Oct 2012 11:41:31 +0200, Andrea Aime wrote:

> Dall'altra parte abbiamo un process (WMTS) che deve prendere N tiles,
> necessariamente in PNG (o eventualmente TIFF) visto che abbiamo
> bisogno
> della traslucenza, combinarle in un'unica immagine, e produrre un
> file in
> output, eventualmente applicando una quantizzazione al volo se si
> vuole
> servire un PNG8.
> La parte lenta qui è aprire le n PNG
>

suppongo che spesso questa sia esattamente la parte che spesso sfugge
all'attenzione di molti.
PNG e' sicuramente un ottimo formato, e' lossless e supporta pienamente
le trasparenze; ma in termini velocistici non e' esattamente un
fulmine.

giusto per fare la classica comparazione tra mele ed arance; JPEG in
confronto a PNG e' un codec decisamente piu' veloce, specie se si usa
la recente libjpeg-turbo su qualche processore Intel di ultima
generazione,
che supporta appositi codici macchina ottimizzati direttamente in
hardware.

se poi si tratta di un PNG RGB (PNG24), che magari comprende anche il
canale
ALPHA (trasparenza), allora il tempo di compressione diventa
sicuramente
tutt'altro che trascurabile.
semplificando ed approssimando: libpng comprime ciascun canale per
proprio
conto; quindi un PNG24+ALPHA (rgb + trasparenza) in pratica richiede
ben
quattro passate successive di compressione.

applicando qualche opportuna quantizzazione si puo' facilmente ottenere
un PNG8 (palette-based), che e' sicuramente piu' leggero, ed anche piu'
veloce da produrre.
ma un buon algoritmo di quantizzazione capace di offrire buoni
risultati
visivi (tipo median cut) tende a consumare moltissimi cicli macchina, e
quindi introduce ulteriori rallentamenti.

il recentissimo formato Google WEBP potrebbe anche essere in teoria una
alternativa appetibile: e' sia lossy che near-lossy (molto compatto, ma
con alta qualita' apparente), ed a differenza di JPEG supporta anche le
trasparenze.
peccato pero' che il compressore WEBP e' quanto di piu' lento mi sia
mai capitato di incontrare (a parte qualche penoso codec JPEG2000
open source come Jasper o OpenJpeg): per fortuna la decompressione e'
invece molto efficiente.

insomma, o per un verso o per l'altro la gestione dinamica di un
elevato
volume di immagini compresse richiede comunque risorse di calcolo molto
ingenti.
usare formati non compressi garantisce sicuramente risultati
velocistici
di eccellenza, ma impone l'uso di spazi di archiviazione
impressionanti.

purtroppo questo e' quanto offre lo stato dell'arte corrente: temo che
non esistano scorciatoie facili ed indolori.

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012