[Gfoss] spatialite e geoserver

a.furieri a lqt.it a.furieri a lqt.it
Ven 10 Giu 2011 12:14:04 CEST


On Thu, 09 Jun 2011 20:20:49 +0200, benedetto.porfidia wrote
> gli include e le lib sono necessarie? dove vanno messe?
>

no, a te non servono affatto. servono invece agli 
sviluppatori che intendono compilare codice C/C++

> o basta solo copiare le dll in c:blabla\system32?
>

si, a te basta il mero supporto binario di run-time,
cioè le DLLs
 
> perchè le dll incriminate (esattamente il pacchetto del link che hai 
>  indicato) le ho già installate (sempre in c_win_sys32) come anche 
> le  dll di geos e proj. Adesso purtroppo sono a casa e non ho un pc 
> windows per provare.
> 

mmm ... allora sono dolori di pancia.
in bocca al lupo, e buon debugging ;-)
* nota per il lettore: fare questo tipo di debugging
  su WinOz è come andare a cercare un ago in un pagliaio 
  in piena notte nell'oscurità più totale :D


> In ogni caso il mio obiettivo è testare un WFS per circa un paio di 
> GB  di dati (circa 500K poligoni) che vorrei fossero sempre 
> residenti in  RAM; ovviamente il servizio non deve erogare tutto il 
> dataset in una  volta, ma vorrei che tutto il dataset sia sempre 
> "pronto" evitando i  passaggi di lettura su disco. E' sensato oppure 
> è un'idea totalmente fuori di senno? :-)
> 

no, non è affatto fuori di senno.
BTW sqlite implementa un meccanismo molto elegante che ti
consente di trasferire tutto un intero DB in ram (e poi
eventualmente di salvarlo nuovamente su disco al termine).
ed ovviamente le performances diventano "oltre il
muro del suono" :-)
ma non saprei proprio dirti se il connector JDBC supporti
questa opzione ... a naso direi proprio di no.
in ogni caso puoi ottenere lo stesso risultato 
semplicemente dichiarando una cache SQLite molto
generosa:
http://www.sqlite.org/pragma.html#pragma_cache_size

n.b.: una PRAGMA la esegui esattamente come se fosse
una SELECT, quindi basta che la esegui nelle primissime
fasi di avvio della connessione: ma dubito molto che
si possa fare tramite GeoServer.

l'unica differenza è che nel primo caso sicuramente
tutto il db è residente in memoria, nel secondo caso
(cache) le pagine verranno caricate in memoria solo
nel momento in cui sarenno via via interrogate
(insomma, hai un costo di "primo accesso" più alto).


> Questa prova la sto facendo su una normale workstation con 4GB di 
> ram   e un dataset limitato di 50k poligoni
> 

qua sbatti contro un muro di cemento armato :-(
per WinOz abbiamo disponibile solo la versione 32 bit, 
che per ovvi motivi non riesce proprio a vedere più di
2 GB RAM (realisticamante, 1.5GB nel mondo reale).
non dovresti avere problemi con il dataset castrato,
ma con quello completo vai sicuramente fuori memoria.
magari potresti provare su Linux 64 bit.

in ogni caso tieni presente che se il DB "sequestra"
una quantità esagerata di RAM, poi probabilmente le
performances globali *calerano*, perchè entreranno 
in sofferenza la JVM ed altri componenti critici ...
insomma, andrebbe monitorato accuratamente facendo
un tuning ultra-fine per avere dei benefici reali.

ciao Sandro


Maggiori informazioni sulla lista Gfoss