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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione Gfoss@lists.gfoss.it 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 rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011
