Hi.
We are developing a function to store session information, for use in a HA
environment.
However we are not reaching the throughput we want.
Since its for persistance, we need to do autocommit on all operations.
The Table has two indexes and a blob of data.
The first index is a char(20) and
Hello, speed depends also on JVM. What version and JVM parameters are you using?
On 10/16/08, Jonas Ahlinder [EMAIL PROTECTED] wrote:
Hi.
We are developing a function to store session information, for use in a HA
environment.
However we are not reaching the throughput we want.
Since its
Jonas Ahlinder [EMAIL PROTECTED] writes:
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm sata disks I get over 900 tps, while on a server (
running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
Could it be that the desk top machine has disk caching
The first issue is that on a desktop machine ( running vista ) with
two 7.2k rpm sata disks I get over 900 tps, while on a server (
running RHEL 5 ) and two 15k rpm sas disks, I get around 250 tps.
Is your benchmark client multi-threaded? Or single-threaded?
During the run(s) are your
Hello.
I do believe that both desktop and server has disk cache turned on, but i will
definitely confirm this in the morning.
Also im aware that this impacts durability.
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 5:38 PM
The benchmark client is single-threaded atm.
To run it multi-threaded some sort of locking will most likely have ot me
implemented ( which will be done as soon as we can confirmt he performance is
ok ).
I have tried running more threads, and it does seem to give better performance,
but the
Windows on desktop by default will cache writes to disk whereas your
Linux may not. Also you may be running Windows JVM client hotspot and
Linux could be server hotspot.
On 10/16/08, Jonas Ahlinder [EMAIL PROTECTED] wrote:
Hi.
On Windows i use 1.6.0_10 and on Linux 1.6.0_10rc2 ( the final
I have tried running more threads, and it does seem to give
better performance, but the current state of the client
doesnt really allow for reliable testresults.
With autocommit on, and with the disk running 100% usage
( and quite a bit of wait queue at least on Linux ) do
you think
Jonas Ahlinder wrote:
The benchmark client is single-threaded atm.
To run it multi-threaded some sort of locking will most likely have ot me
implemented ( which will be done as soon as we can confirmt he performance is
ok ).
I have tried running more threads, and it does seem to give better
