On 26 Jan 2012, at 23:04, Sanne Grinovero wrote:
Very nice!
All my previous tests also confirm that there is a correlation between PUT
and GET performance, when one increases the other goes down.
These PUT operations are doing a GET as well, correct? I'd love to see such
graphs using
On 27 Jan 2012, at 11:07, Mircea Markus wrote:
These PUT operations are doing a GET as well, correct? I'd love to see such
graphs using SKIP_REMOTE_LOOKUP.
it is configured with unsafe return values. With safe return, the values
might get even better…
Eh? Why would safe return values
On 27 January 2012 11:07, Mircea Markus mircea.mar...@jboss.com wrote:
On 26 Jan 2012, at 23:04, Sanne Grinovero wrote:
Very nice!
All my previous tests also confirm that there is a correlation between PUT
and GET performance, when one increases the other goes down.
These PUT operations
10 is an awfully small value; in my experience (I had a default of 100
for my JGroups perf tests), this made the tests longer than with the
default (which is 1 IIRC) !
On 1/27/12 12:20 PM, Sanne Grinovero wrote:
On 27 January 2012 11:07, Mircea Markusmircea.mar...@jboss.com wrote:
On
Are both reads and writes marked as OOB ? Then they share the same OOB
thread pool !
We do mark reads as OOB
(DistributionManagerImpl.retrieveFromRemoteSource). So reads and
writes share the same OOB pool.
I was looking an non-trnasactional puts, and these are not OOB. This benchmark
On 27 Jan 2012, at 10:59, Manik Surtani wrote:
On 26 Jan 2012, at 23:04, Sanne Grinovero wrote:
How long are you warming up the VM? As mentioned in the other thread, I've
discovered that even under high load it will take more than 15 minutes
before all of Infinispan's code is running
On 27 January 2012 11:37, Mircea Markus mircea.mar...@jboss.com wrote:
On 27 Jan 2012, at 10:59, Manik Surtani wrote:
On 26 Jan 2012, at 23:04, Sanne Grinovero wrote:
How long are you warming up the VM? As mentioned in the other thread, I've
discovered that even under high load it will
On 27 Jan 2012, at 11:20, Sanne Grinovero wrote:
On 27 January 2012 11:07, Mircea Markus mircea.mar...@jboss.com wrote:
On 26 Jan 2012, at 23:04, Sanne Grinovero wrote:
Very nice!
All my previous tests also confirm that there is a correlation between PUT
and GET performance, when one
On 27 Jan 2012, at 11:36, Bela Ban wrote:
10 is an awfully small value; in my experience (I had a default of 100
for my JGroups perf tests), this made the tests longer than with the
default (which is 1 IIRC) !
default is 1500:
My experiments where using the default JVM settings regarding compile
settings, with these others:
-Xmx2G -Xms2G -XX:MaxPermSize=128M -XX:+HeapDumpOnOutOfMemoryError
-Xss512k -XX:HeapDumpPath=/tmp/java_heap
-Djava.net.preferIPv4Stack=true -Djgroups.bind_addr=127.0.0.1
On 27 Jan 2012, at 13:31, Sanne Grinovero wrote:
My experiments where using the default JVM settings regarding compile
settings, with these others:
-Xmx2G -Xms2G -XX:MaxPermSize=128M -XX:+HeapDumpOnOutOfMemoryError
-Xss512k -XX:HeapDumpPath=/tmp/java_heap
-Djava.net.preferIPv4Stack=true
On Fri, Jan 27, 2012 at 3:43 PM, Mircea Markus mircea.mar...@jboss.com wrote:
On 27 Jan 2012, at 13:31, Sanne Grinovero wrote:
My experiments where using the default JVM settings regarding compile
settings, with these others:
-Xmx2G -Xms2G -XX:MaxPermSize=128M -XX:+HeapDumpOnOutOfMemoryError
On 1/26/12 6:58 PM, Mircea Markus wrote:
Hi,
As discussed on another thread, I've hacked the remote get to only go to a
single node. The performance of put almost doubled, whilst the one of gets
decreased by about 10 percent.
The performance decrease for gets is understandable, but I can't
13 matches
Mail list logo
