consiglio HARDWARE per sistema webgis

[Andrea Peri]

>Per arrivare a 24 ore su 120 mila tile ho dovuto assumere di avere un solo
>core (non adeguato per un web-gis in ogni caso) e 6 secondi di tempo
>medio per la risposta a una richiesta di una metatile 4x4, di nuovo
>un tempo veramente lungo.

Non è facile stabilire quanti core sta usando un tomcat.
Anche perche' su un core ci possono finire piu' threads e decide il gestore su quale core andare.

Intanto dipende da quale JVM si sta usando (sun-jdk o altro ?).
Posso sbagliarmi, ma a sensazione mia, se usi la jdk-sun allora la JVM è in grado di accedere a piu' core, se invece usi la JVM foss temo che essa usa il medeismo core ove gira l'istanza Tomcat. (spero di sbagliarmi naturalmente)

Poi occorre stabilire se sei l'unico utente oppure se ci sono altri utenti di altre webapps che stanno accedendo a tale macchina.

Infine serve che le richieste (che si vuole vadano a finire su core distinti siano contemporanee.

Questo è forse il dettaglio piu' spinoso.
Non conosco nei dettagli geowebcache, se le effettua sequenzialmente in maniera sincrona ,
cosa che a me parrebbe probabile se gira sulla medesima istanza tomcat del geoserver.

Io direi che è molto probabile che finisca tutto sul medesimo core.

Se ti va bene, il geoserver finisce su un altro core.

--
-----------------
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

[Andrea Aime]

2012/10/24 Andrea Peri <[hidden email]>:
>>Per arrivare a 24 ore su 120 mila tile ho dovuto assumere di avere un solo
>>core (non adeguato per un web-gis in ogni caso) e 6 secondi di tempo
>>medio per la risposta a una richiesta di una metatile 4x4, di nuovo
>>un tempo veramente lungo.
>
>
> Non è facile stabilire quanti core sta usando un tomcat.
> Anche perche' su un core ci possono finire piu' threads e decide il gestore
> su quale core andare.

Il kernel del sistema operativo, non la JVM (i tempi dei green threads sono
andati da una vita).

> Intanto dipende da quale JVM si sta usando (sun-jdk o altro ?).
> Posso sbagliarmi, ma a sensazione mia, se usi la jdk-sun allora la JVM è in
> grado di accedere a piu' core, se invece usi la JVM foss temo che essa usa
> il medeismo core ove gira l'istanza Tomcat. (spero di sbagliarmi
> naturalmente)

Tutte le JVM moderne (Oracle, OpenJDK, IBM, JRockit)
mappano thread di macchina virtuale su un thread nativo, a quel punto
è il kernel a decidere dove far eseguire il thread.

> Questo è forse il dettaglio piu' spinoso.
> Non conosco nei dettagli geowebcache, se le effettua sequenzialmente in
> maniera sincrona ,
> cosa che a me parrebbe probabile se gira sulla medesima istanza tomcat del
> geoserver.

Può girare sia internamente che esternamente, è una scelta (su hardware modesto
meglio tenerla integrata, su una installazione enterprise meglio fuori
di fronte a
un cluster di istanze di GeoServer).
Il seeding delle tiles usa un numero configurabile di thread, da 1 a 32 se non
ricordo male.
Quando si effettua il seeding il numero ottimale di thread dipende anche da cosa
c'e' alle spalle di GWC, se un WMS solo o un cluster di macchine, per
il funzionamento
a tile cache già popolata benchmarks dimostrano che il throughput massimo si
ottiene con un numero di richieste parallele pari a 4 volte il numero
di core disponibili
(fisici e logici, se si ha un core i7 con 4 core + HT il numero ottimale è 32).

> Io direi che è molto probabile che finisca tutto sul medesimo core.

Molto improbabile nel momento in cui si scelga di usare più di un thread
per il seeding, a meno che il sistema operativo in questione non abbia
uno scheduler dei thread mal disegnato: sulle macchine che ho potuto
testare personalmente quando GWC fa un seeding, e nell'ipotesi
che anche GeoServer sia sulla stessa macchina, tutti i core fisici
(e anche quelli virtuali, HT) sono occupati al 100% o prossimi a tale valore.

> Se ti va bene, il geoserver finisce su un altro core.

Se sono integrate il seeding avviene sul medesimo thread, con GWC che
prende direttamente l'immagine generata da GeoServer senza dover passare
per un formato di rete intermedio (png, tiff, ecc), se sono separate sta al
sistema operativo decidere, ma mentre GeoServer produce la metatile richiesta
da GWC il corrispondente thread di seeding di è in attesa sulla chiamata HTTP.

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

[a.furieri]

On Thu, 25 Oct 2012 21:26:39 +0200, Andrea Aime wrote:

> 2012/10/24 Andrea Peri <[hidden email]>:
>
> <snip>
>
>> Non è facile stabilire quanti core sta usando un tomcat.
>> Anche perche' su un core ci possono finire piu' threads e decide il
>> gestore
>> su quale core andare.
>
> Il kernel del sistema operativo, non la JVM (i tempi dei green
> threads sono
> andati da una vita).
>
> <snip>
>

Andrea A. ed Andrea P.,

grazie, ma veramente tante grazie ad entrambi.

era da moltissimi mesi che non mi capitava di leggere sulle nostre
ML un post cosi' interessante, concettualmente denso, ricco di
contenuti e di informazioni oggettive saldamente argomentate.
vi ho letto tutto di un fiato, e poi sono anche andato indietro
a rileggermi tutti i post precedenti del thread per seguirvi meglio.

ottima analisi; e' veramente una ricca miniera di spunti di
riflessione, e contiene un sacco di considerazioni sistemistiche
di gran pregio.

complementi a tutti e due; gran bel lavoro ;-)

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

[margherita]

2012/10/25 <[hidden email]>

Andrea A. ed Andrea P.,

grazie, ma veramente tante grazie ad entrambi.

era da moltissimi mesi che non mi capitava di leggere sulle nostre
ML un post cosi' interessante, concettualmente denso, ricco di
contenuti e di informazioni oggettive saldamente argomentate.
vi ho letto tutto di un fiato, e poi sono anche andato indietro
a rileggermi tutti i post precedenti del thread per seguirvi meglio.

ottima analisi; e' veramente una ricca miniera di spunti di
riflessione, e contiene un sacco di considerazioni sistemistiche
di gran pregio.

complementi a tutti e due; gran bel lavoro ;-)

ciao Sandro

Infatti e poiche` sarebbe un peccato perderne traccia e filo, vi chiederei di trasferire sul wiki alla fine... 

grazie!

ciao madi 

--
Margherita DI LEO  

Postdoctoral Researcher  
European Commission - DG JRC 
Forest Resources and Climate    
I-21020 Ispra (VA) - Italy - TP 261 
        
Tel. [phone]   
[hidden email]

_______________________________________________
[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