Hi,
I write some tracing code in MetatileMapProducer to try to find the
QuickTileCache hit rate. Then I find that nearly all tiles miss all
the time, that is, QuickTileCache caches nothing. I think there may be
some problems. Does any one met the same problem?
Thank you.
pi3orama ha scritto:
Hi,
I write some tracing code in MetatileMapProducer to try to find the
QuickTileCache hit rate. Then I find that nearly all tiles miss all
the time, that is, QuickTileCache caches nothing. I think there may be
some problems. Does any one met the same problem?
Hello again 
Hem, no, I did not make much checks in fact, always in a hurry (I'm the one that developed that cache).
I can tell you I've modified the code for 1.6.0 thought... where are you
measuring the hit ratio?
Another detail, that tile cache is just meant to keep data for a very
brief amount of time, so that all the tiles in the tilecache are served
back to OpenLayers client making the request (since it will ask for
nearby tiles just after then first one). It's not meant as a real
tile cache. Yet, even with that, the hit ratio should be at least 50%...
Cheers
Andrea
Hi,
Sorry but I don't really know which version we using. Most of the code
of my geoXXX was checked from svn at Dec.6, 2007. Then we stop catch
up with svn because of the quickly changing.
We add our tracing code in produceMap() of MetatileMapProducer (in
fact, we are trying to add a new storage level below the tilecache),
and then we found that when we keep browsing same maps, the cache miss
nearly all the time (that is, our new level has to deal with a lot of
same requests). We switch SoftValueHashMap to java.util.Hashtable, it
then works as we think it should be. But we all know that using
java.util.Hashtable is not the right thing...
On Wed, Feb 27, 2008 at 10:16 PM, Andrea Aime <aaime@anonymised.com> wrote:
pi3orama ha scritto:
> Hi,
> I write some tracing code in MetatileMapProducer to try to find the
> QuickTileCache hit rate. Then I find that nearly all tiles miss all
> the time, that is, QuickTileCache caches nothing. I think there may be
> some problems. Does any one met the same problem?Hello again
Hem, no, I did not make much checks in fact, always in a hurry (I'm the
one that developed that cache).
I can tell you I've modified the code for 1.6.0 thought... where are you
measuring the hit ratio?Another detail, that tile cache is just meant to keep data for a very
brief amount of time, so that all the tiles in the tilecache are served
back to OpenLayers client making the request (since it will ask for
nearby tiles just after then first one). It's not meant as a real
tile cache. Yet, even with that, the hit ratio should be at least 50%...Cheers
Andrea
pi3orama ha scritto:
Hi,
Sorry but I don't really know which version we using. Most of the code
of my geoXXX was checked from svn at Dec.6, 2007. Then we stop catch
up with svn because of the quickly changing.
Interesting. Are you customizing GeoServer? Interested in joining
the developer team?
We add our tracing code in produceMap() of MetatileMapProducer (in
fact, we are trying to add a new storage level below the tilecache),
and then we found that when we keep browsing same maps, the cache miss
nearly all the time (that is, our new level has to deal with a lot of
same requests). We switch SoftValueHashMap to java.util.Hashtable, it
then works as we think it should be. But we all know that using
java.util.Hashtable is not the right thing...
Hum, the soft value hash map throws away data if the virtual machine
is under memory pressure. First thing is to check is if the VM
is started with enough memory to handle the in memory caching
(that is, what happens if you start it with -Xms64m -Xmx128m, for example?)
There is also another a parameter you can use to make
soft references a bit more resistant to gc cycles, which is
reported in our "GeoServer in production" page:
http://geoserver.org/display/GEOSDOC/6+GeoServer+in+Production+Environment
which in particular is:
-XX:SoftRefLRUPolicyMSPerMB=36000
If that does not help either, we should have a look in the soft
hash map behaviour and look for a bug.
Let me know how it goes
Cheers
Andrea
On Wed, Feb 27, 2008 at 10:37 PM, Andrea Aime <aaime@anonymised.com> wrote:
pi3orama ha scritto:
> Hi,
> Sorry but I don't really know which version we using. Most of the code
> of my geoXXX was checked from svn at Dec.6, 2007. Then we stop catch
> up with svn because of the quickly changing.Interesting. Are you customizing GeoServer? Interested in joining
the developer team?> We add our tracing code in produceMap() of MetatileMapProducer (in
> fact, we are trying to add a new storage level below the tilecache),
> and then we found that when we keep browsing same maps, the cache miss
> nearly all the time (that is, our new level has to deal with a lot of
> same requests). We switch SoftValueHashMap to java.util.Hashtable, it
> then works as we think it should be. But we all know that using
> java.util.Hashtable is not the right thing...Hum, the soft value hash map throws away data if the virtual machine
is under memory pressure. First thing is to check is if the VM
is started with enough memory to handle the in memory caching
(that is, what happens if you start it with -Xms64m -Xmx128m, for example?)There is also another a parameter you can use to make
soft references a bit more resistant to gc cycles, which is
reported in our "GeoServer in production" page:
http://geoserver.org/display/GEOSDOC/6+GeoServer+in+Production+Environment
which in particular is:
-XX:SoftRefLRUPolicyMSPerMB=36000If that does not help either, we should have a look in the soft
hash map behaviour and look for a bug.Let me know how it goes
Cheers
Andrea
We run geoserver(and other support packages, like geotools, nearly 100
projects) in eclipse in a 1GB memory machine. Though it not works
very fast, nothing shows we met memory bottleneck.We use topp:states
for test, in firefox, in the initial perspective, press shift+F5 again
and again, the tilecache always miss. You've wrote some monitor code,
then you can try it yourself. Below is the result (we change the log
level to warn for simple).
Please note that there are only 2 meta tiles in above scenario. And
also the timestamp. We've added "-XX:SoftRefLRUPolicyMSPerMB=36000" to
eclipse's "VM arguments".
2008-02-27 22:52:51.755:/geoserver:INFO: Initializing
WebApplicationContext for Struts ActionServlet 'action', module ''
2008-02-27 22:52:51.818::INFO: Started SocketConnector @ 0.0.0.0:8080
2008-02-27 22:52:56.473:/geoserver:INFO: Loading
WebApplicationContext for Spring FrameworkServlet 'dispatcher'
27 Feb 22:52:58 WARN [map.metatile] - Looked for meta tile 0, 0in cache: hit!
27 Feb 22:52:58 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:52:58 WARN [map.metatile] - Looked for meta tile -3, 0in cache: hit!
27 Feb 22:53:03 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:03 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:03 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
27 Feb 22:53:11 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:11 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:11 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
27 Feb 22:53:19 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:19 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:19 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
27 Feb 22:53:26 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:26 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:26 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
...
OK, you win. The monitor code you wrote is:
... (tile == null) ? "hit!" : "miss" ....
After adjust the memory arguments, the tilecache works. Thank you.
On Wed, Feb 27, 2008 at 11:11 PM, pi3orama <pi3orama@anonymised.com> wrote:
On Wed, Feb 27, 2008 at 10:37 PM, Andrea Aime <aaime@anonymised.com> wrote:
> pi3orama ha scritto:
>
> > Hi,
> > Sorry but I don't really know which version we using. Most of the code
> > of my geoXXX was checked from svn at Dec.6, 2007. Then we stop catch
> > up with svn because of the quickly changing.
>
> Interesting. Are you customizing GeoServer? Interested in joining
> the developer team?
>
>
> > We add our tracing code in produceMap() of MetatileMapProducer (in
> > fact, we are trying to add a new storage level below the tilecache),
> > and then we found that when we keep browsing same maps, the cache miss
> > nearly all the time (that is, our new level has to deal with a lot of
> > same requests). We switch SoftValueHashMap to java.util.Hashtable, it
> > then works as we think it should be. But we all know that using
> > java.util.Hashtable is not the right thing...
>
> Hum, the soft value hash map throws away data if the virtual machine
> is under memory pressure. First thing is to check is if the VM
> is started with enough memory to handle the in memory caching
> (that is, what happens if you start it with -Xms64m -Xmx128m, for example?)
>
> There is also another a parameter you can use to make
> soft references a bit more resistant to gc cycles, which is
> reported in our "GeoServer in production" page:
> http://geoserver.org/display/GEOSDOC/6+GeoServer+in+Production+Environment
> which in particular is:
> -XX:SoftRefLRUPolicyMSPerMB=36000
>
> If that does not help either, we should have a look in the soft
> hash map behaviour and look for a bug.
>
> Let me know how it goes
> Cheers
> Andrea
>We run geoserver(and other support packages, like geotools, nearly 100
projects) in eclipse in a 1GB memory machine. Though it not works
very fast, nothing shows we met memory bottleneck.We use topp:states
for test, in firefox, in the initial perspective, press shift+F5 again
and again, the tilecache always miss. You've wrote some monitor code,
then you can try it yourself. Below is the result (we change the log
level to warn for simple).Please note that there are only 2 meta tiles in above scenario. And
also the timestamp. We've added "-XX:SoftRefLRUPolicyMSPerMB=36000" to
eclipse's "VM arguments".2008-02-27 22:52:51.755:/geoserver:INFO: Initializing
WebApplicationContext for Struts ActionServlet 'action', module ''
2008-02-27 22:52:51.818::INFO: Started SocketConnector @ 0.0.0.0:8080
2008-02-27 22:52:56.473:/geoserver:INFO: Loading
WebApplicationContext for Spring FrameworkServlet 'dispatcher'
27 Feb 22:52:58 WARN [map.metatile] - Looked for meta tile 0, 0in cache: hit!
27 Feb 22:52:58 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:52:58 WARN [map.metatile] - Looked for meta tile -3, 0in cache: hit!
27 Feb 22:53:03 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:03 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:03 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
27 Feb 22:53:11 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:11 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:11 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
27 Feb 22:53:19 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:19 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:19 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
27 Feb 22:53:26 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:26 WARN [map.metatile] - Looked for meta tile 0, 0in cache: miss
27 Feb 22:53:26 WARN [map.metatile] - Looked for meta tile -3, 0in cache: miss
...
pi3orama ha scritto:
OK, you win. The monitor code you wrote is:
... (tile == null) ? "hit!" : "miss" ....
After adjust the memory arguments, the tilecache works. Thank you.
Aah, so in fact it's doing hits most of the time
Nice to know
Cheers
Andrea
pi3orama ha scritto:
OK, you win. The monitor code you wrote is:
... (tile == null) ? "hit!" : "miss" ....
After adjust the memory arguments, the tilecache works. Thank you.
Ah, I've just now realized that you were using some logging
code that was already in GeoServer. I fixed it, thanks for
reporting
Cheers
Andrea