On 19 Jun, Rickard �berg wrote:
> Hi!
>
> Peter Antman wrote:
>> OK, this is not a benchmark, and probably not even worth considering a
>> real timing, because there are a lot of different varaibles that have not
>> been contrained enough. I just wanted to hear a first impression. Is this
>> already known? May I have done something completly wrong, etc...
> <snip>
>
> I have been looking into performance a lot lately. There are some
> strange things going on.
>
> First of all, you should use the latest version of jBoss from CVS.
Hi, I checked outv the latest version, and after fixing a lot of merge
conflicts I started it, and it no longer works. Is there any important
(documented/undocumented) changes that hace occured since javaOne).
Here are my problems:
java.lang.IllegalStateException: There is no TransactionManager in
JNDI!
at org.jboss.jdbc.XADataSourceLoader.<init>(XADataSourceLoader.java:48)
at java.lang.reflect.Constructor.newInstance(Native Method)
at javax.management.MBeanServer.internal_instantiate(MBeanServer.java:2204)
at javax.management.MBeanServer.createMBean(MBeanServer.java:717)
at javax.management.loading.MLet.getMBeansFromURL(MLet.java:385)
at javax.management.loading.MLet.getMBeansFromURL(MLet.java:208)
at org.jboss.Main.<init>(Main.java:111)
at org.jboss.Main.<init>(Main.java:86)
at org.jboss.Main$1.run(Main.java:76)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.Main.main(Main.java:67)
Hm, never seen before.
[Container factory] javax.naming.NameNotFoundException: xa.ejbPool not
bound
In the docukmentation for minerva, this was stated to be the name that
should be mapped if I have an entry like this:
<MLET CODE = "org.jboss.jdbc.XADataSourceLoader" ARCHIVE="jboss.jar,minerva.jar"
CODEBASE="../lib/ext/">
<ARG TYPE="java.lang.String" VALUE="ejbPool">
<ARG TYPE="java.lang.String" VALUE="org.jboss.minerva.xa.XADataSourceImpl">
<ARG TYPE="java.lang.String" VALUE="jdbc:postgresql://localhost/news">
<ARG TYPE="java.lang.String" VALUE="pra">
<ARG TYPE="java.lang.String" VALUE="none">
<ARG TYPE="java.lang.String" VALUE="">
<ARG TYPE="java.lang.Integer" VALUE="2">
<ARG TYPE="java.lang.Integer" VALUE="5">
<ARG TYPE="java.lang.String" VALUE="GCEnabled=true;ShrinkingEnabled=true">
</MLET>
And then it ends with:
[JMX RMI Adaptor] Starting
[JMX RMI Adaptor] Started
at org.jboss.Main.<init>(Main.java:152)
at org.jboss.Main.<init>(Main.java:86)
at org.jboss.Main$1.run(Main.java:76)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.Main.main(Main.java:67)
[Default] java.lang.ClassCastException: javax.management.RuntimeMBeanException
This was not to fun I have to say.
>
> Then there's the following issues (that I know of):
> * The JNDI implementation used to be slow if you included new
> InitialContext() in your code since no caching was done. This has been
> changed so that the server connection is cached, and the VM-local case
> is also optimized now.
>
> * Do you look up the home each time? That is an additional performance
> hit.
Yes I do. Which is basicly what you would have to do in a web
environement.
>
> * The strangest thing is that returning a EJBObject is extremely slow.
> Right now I have a call that takes an EJBObject and returns it, which
> takes 15 ms to invoke. The same method with a String takes 3 ms. One
> thing I found was that RM I was doing DGC calls when the EJBObject
> entered the VM, but it didn't reuse connections to the server. This was
> not only a performance hit, but also led to OutOfMemory exceptions. So
> something is going on which is making it very slow. One optimization I
> have found is to turn off the security manager, which speeds things up
> significantly. I will add this as a configuration option.
>
> * Many of the Entity plugins (caching mainly) are not yet optimized.
>
> I am glad that you are doing performance benchmarks, and while your
> numbers are a bit extreme I think I can account for most of the
> problems. Could you please send me the code and I can do some testing
> here? This would help enourmously in locating issues.
Yes I will pack it later, but it is based on Percolator, so you will
probably need to use Percolator if you are interested in rebuilding.
Regards
Peter
>
> regards,
> Rickard
>
>>
>> Here it comes:
>>
>> I did a small timing on a bean developed with Percolator
>> (http://www.percolator.org) on three different EJB servers: jboss, jonas
>> and Weblogic 5.1. It is a rather small entity bean and the test was done
>> from one client only. First it creates 1000 entitys, then it looks up each
>> entity (in percolator mening getting all the data over in a value holder),
>> then it just lookes up the same entity 1000 times.
>>
>> The result? For weblogic this took about 50ms for each operation. Creating
>> a bean took 50ms, looking it up 49ms. With jonas, this took about 2-3
>> times longer. (184ms to create, 169ms to look up each and 128ms to lookup
>> one several times). But with jboss, this took a lot longer. It took about
>> 15 times longer to create a bean compared to WLS5.1, and about 7-8 times
>> longer to lookup a bean.
>>
>> I have to admit, they was not even run on the same JVM, WLS was Sun 1.2.2
>> for Linux and Jonas 1.3 for Linux (and I could not find a way to turn of
>> all the logging in jboss), but it still sees to be a to huge different to
>> really be only about runtime differenses, or am I wrong? Is there a way to
>> speed up jboss? Or is this low performance a known problem?
>>
>> Hope you don't take me wrong. I would really like to see jboss beeing one
>> of the performance leader (it will make it a lot easier to recommend it
>> then).
>>
>> Greetings
>> Peter
>>
>> Oh, here are the numbers:
>>
>> (In millis)
>> Create 1000 Articles Find 1000 Articles Lookup 1 article 1000
>> times
>> Jonas 184553 (184) 169045 (169) 128174 (128)
>> WLS 49886 (50) 48867 56429
>> jboss 733522 (733) 373391 (373) 379657 (379)
>>
>> ------------------------------------------------------------
>> Peter Antman Technology in Media, Box 34105 100 26 Stockholm
>> Systems Architect WWW: http://www.tim.se
>> Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
>> Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
>> ------------------------------------------------------------
>>
>> --
>> --------------------------------------------------------------
>> To subscribe: [EMAIL PROTECTED]
>> To unsubscribe: [EMAIL PROTECTED]
>> Problems?: [EMAIL PROTECTED]
>
--
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
