Sorry for not replying to the topic, I was busy by tuning the performance of
database (Firebird 0.9.4 p1). Now everything is ok. I don't use PosgreSQL
any longer, because even the 7.x version is slower than Firebird (also I am
using InterBase since the version 4.0, and I do like it! :))
> Can you send a snip of your client code? depending on how you
> do this, it can really hurt! The main problem is having the
> client initiate M transactions per row instead of one
> (M being the number of method invocations).
client code is something like this:
//create accounts and corresponding profiles
HashMap accounts = new HashMap();
AccountHome acctHome = (AccountHome)ctx.lookup("accounts");
ProfileHome profHome = (ProfileHome)ctx.lookup("profiles");
for(int i = 0; i < 100 * 1000; i++) {
accounts.put(acctHome.create("test" + i), profHome.create("test" + i));
}
then :
//update profiles
Iterator iterator = accounts.keySet().iterator();
while(iterator.hasNext())
((Profile)accounts.get(iterator.next())).update(new TestProfile("test"));
and then remove accounts and profiles (similar to create).
> Other JAWS tips:
> With a table this size, you _need_ to make sure that the
> primary key is created in the database (note that the
> JAWS persistence manager defaults to _not_ creating a
> primary key - if you're letting JAWS create the
> table, add a <pk-constraint>true</pk-constraint> into the
> entity tag for that bean in jaws.xml.
Thank you for the tip. The absence of the primary key index was definitely
the reason of the great slowdown. It turned out to have exponential growth
in case of select count(*) from my_bean_table where id = '..' when no index
was available. After creating indexes by hands everything works great.
> Put the <tuned-updates>true</tuned-updates> in your jaws.xml
> also. This avoids updating unchanged columns, particularly the
> primary key. In JBoss 2.4 (next release) primary key columns
> will never be updated by JAWS. Note that if your primary key
> changes, it isn't really a primary key - see Codd.
That also helped a lot. And I completely agreed with your note about the
immutability of the PK.
At the end I want to put here some results:
I was load testing the JBoss on two machines:
M1 (Pentium III 550 Mhz, 256 Mb RAM, Win2k Prof) and M2 (Pentium II 350 MHz,
128 Mb RAM, Debian Linux).
The M1 machine results:
InterBase (no indexes)
--------------
Creating 300 accounts + 300 profiles...36002 ms
Updating 300 profiles...3605 ms
Removing 300 accounts + 300 profiles...41159 ms
JDataStore
----------------
Creating 300 accounts...21360 ms
Updating 300 profiles...3325 ms
Removing 300 accounts...24616 ms
InstantDB and PostgreSQL were definitely slower, HypersonicSQL was almost
the same (test results were not included because the HypersonicSQL is not
acceptable for me in case of fault-tolerance due to the big startup time).
M2 machine results:
Firebird 0.9.4 (with indexes)
--------------
Creating 300 accounts + 300 profiles...23182 ms
Updating 300 profiles...2861 ms
Removing 300 accounts + 300 profiles...15858 ms
Test for 100,000 accounts + 100,000 profiles crashed on the client side
because of java.lang.OutOfMemoryError at ~45,000 accounts and ~45,000
profiles. JBoss behaved perfectly.
More results will be available later after the launch of the application
(approx in one month). Deployment platform is Sun Netra T1 (or something
like this, SPARC 400 MHz, 512 MB RAM).
I would suggest that we create the dedicated page on www.jboss.org to the
more or less extreme JBoss usage. This perfectly exists for
InterBase/Firebird (the largest known database handeled by InterBase is ~200
Gb). This information is very usefull while making the decisions.
Do we have test that can be run for such purposes?
Hope this info is interesting.
Regards,
Roman Rokytskyy.
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
