About threading with coverages. I use tile decoder threads (decoding each
tile in its own thread).
This improves response time and cpu utilization. The threads for themselves
are very short living ones. I have not seen any problems at my installations
or heard something from user mailing list.
see below...
---
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob:+39 333 8128928
http://www.geo-solutions.it
http://geo-
Simone Giannecchini ha scritto:
>> Maybe there is something wrong with the way I've
>> coded up the prefecthin iterator? Someone more familiar
>> with the concurrent java utilitis might be able to tell.
>>
>> More in general, how do people feel about this?
>> Good for a configuration knob in the St
Christian Müller ha scritto:
> Hi, interesting discussion. I did something similar with my imagemosiac
> jdbc module for decoding the tiles.
> Scaled up well, the IBM power p6 has 4 CPUs at 100 %, consuming energy
> like a washing machine.
> I had also the idea using a prefetch mechanism like you
On Tue, Sep 8, 2009 at 5:46 PM, Andrea Aime wrote:
> Hi,
> yesterday I've got confirmation there are some big bad locks
> in the Java rendering subsystem that do prevent a system
> to use a multicore architecture effectively:
> http://jira.codehaus.org/browse/GEOS-3423
>
> In fact I have been obser
Hi, interesting discussion. I did something similar with my imagemosiac jdbc
module for decoding the tiles.
Scaled up well, the IBM power p6 has 4 CPUs at 100 %, consuming energy like
a washing machine.
I had also the idea using a prefetch mechanism like yours using jdbc data
stores, I omitted
Very cool - comments inline.
On Wed, Sep 9, 2009 at 6:32 PM, Andrea Aime wrote:
> I did some more testing and it seems to be a matter of queue depth:
> - with a queue depth of 100 it may get to be 10% slower in some cases
> - with a queue depth of 1000 (which matches the fetch size we use
> by de
Jody Garnett ha scritto:
>> Jody Garnett ha scritto:
>>> Very interesting; I would love it if you made this the default for the
>>> accepts visitor method :-)
>> I would love to get rid of that method. Jody, do you realize
>> you're the only one pushing for that method and pretty much
>> nobody els
> Jody Garnett ha scritto:
>>
>> Very interesting; I would love it if you made this the default for the
>> accepts visitor method :-)
>
> I would love to get rid of that method. Jody, do you realize
> you're the only one pushing for that method and pretty much
> nobody else uses it? ;-)
>
Yeah - an
Jody Garnett ha scritto:
> Very interesting; I would love it if you made this the default for the
> accepts visitor method :-)
I would love to get rid of that method. Jody, do you realize
you're the only one pushing for that method and pretty much
nobody else uses it? ;-)
> I am wondering about
Very interesting; I would love it if you made this the default for the
accepts visitor method :-)
I am wondering about the variably in your test results; is it just
overhead introduced by the blocking queue? Is there any way to start
off without prefetching - and switch over to it if the d
Hi,
yesterday I've got confirmation there are some big bad locks
in the Java rendering subsystem that do prevent a system
to use a multicore architecture effectively:
http://jira.codehaus.org/browse/GEOS-3423
In fact I have been observing CPU utization well below
100% in various mulithreaded benc
12 matches
Mail list logo
