Jboss 3.2.4 slooooooow compared to 2.4.4

[guix]

Hi:
I have an application that I have migrated from Jboss 2.4.4 Tomcat 4.0.1 to Jboss 3.2.4 and to my surprise not jboss starts up slower (even build ing up from the minimal server and adding services till my application worked) but also it runs MUCH MUCH slower... around 3 times.
I have gone through all the (very few published) tricks to make the thing run faster... read only gettters, read.ahead, container commit-options, undeploy services not used, use the Oracle OCI drivers, disable all logs in log4j.xml, even rewrite some code (that anyway it used to rock&roll on jboss 2.4.4) but I can't get the thing to run not even half fast than in 2.4.4 on the same database..... I mean ... Is it that difficult???????

I am seriously considering to quit jboss after 3 years of bliss...

Any ideas on how not to despair?

[clebertsuconic]

I know that this would give you some extra work, but it's just an idea.

I'm writting JBossProfiler.

JBossProfiler works with the concept of LogFiles. Every event is sent to a Log.gz file, and you can analyze it later, or even sent it over the network.

You could run your application with JbossProfiler.
You would Activate it before some test-case. (The profiler stays sleeping until you activate it)

Do the same procedure in both environments. (2.3 and 3.0)


Compare the results between both versions.


You would have to add some filter in your application.

I would recommend you to download jboss-profiler over JBoss's CVS.
Add the -XrunjbossInspector:c:\temp\,ignore=org.apache,start= into your run.bat.

(Make sure you don't have Debug parameters activated. The profiler wouldn't work)


Add the jboss-profiler-noAOP.sar in your deployment directory.


Use the MBean to start the data-capture before your testcase, and after the loading.



Stop after you have some data to analyze.



If you need any help, I'll be glad to help.


Clebert

[triathlon98]

I don't think read-only getters are a good idea. AFAIU this executes code outside of transactions, effectively requireing DB reads. If this does not hurt your performance, then your transaction boundaries are probably not well chosen.

Which commit option are you using. Could Commit option A or else D be used in your case?

Check you DB access. Enable debug log for the cmp stuff to see which SQL queries are executed. Most likely you will see some problems there. If so, ask some specific questions, "it is slow" only allows guesswork.

Joachim

[adrian.brock]

Wrong: read-only getters are executed in the context of the transaction.

I do agree it is impossible to help somebody that doesn't give ANY
useful information. This usually shows a lack of a understanding of the problem.

[guix]

I do agree it is impossible to help somebody that doesn't give ANY
useful information. This usually shows a lack of a understanding of the problem.

See... this is what I am saying... not only jboss is slow "by default" but support always gives grumpy answers... what are your politics on customer service? I mean ok, its free but if you want users don't frighten away.....
Now here is the info you requested would you mind taking a look please?:

Windows XP Dell Optiplex P4 2.6 Hyperthreading enabled 512 RAM
Java 1.4.2
Oracle 8.1.7 running on solaris 450 4processors 4Gb of RAM
Jboss 3.2.4

On Jboss 3.2.4 the same page takes 3 times longer 2.4.4. Default configuration (excep read ahead) on 2.4.4 and the following tweaks on 3.2.4:
- Read Only Getters on al beans.
- Commit Option A
- run .bat modified for more memory and Server Hotsopot -Xms256m -Xmx512m -server
- Services deployed:
client-deployer-service.xml
cache-invalidation-service.xml
hsqldb-ds.xml
iiop-service.xml
jboss-jca.sar
jboss-local-jdbc.rar
jboss-xa-jdbc.rar
mail-service.xml
properties-service.xml
sqlexception-service.xml
transaction-service.xml
user-service.xml
uuid-key-generator.sar

DS file

<xa-datasource>
false
<jndi-name>XAfxokDS</jndi-name>
<track-connection-by-tx>true</track-connection-by-tx>
<isSameRM-override-value>false</isSameRM-override-value>
<xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
<xa-datasource-property name="URL">jdbc:oracle:oci:@myTNS</xa-datasource-property>

<xa-datasource-property name="User">myUser</xa-datasource-property>
<xa-datasource-property name="Password">myPassword<xa-datasource-property>
<!-- Uses the pingDatabase method to check a connection is still valid before handing it out from the pool -->
<!--valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name-->
<!-- Checks the Oracle error codes and messages for fatal errors -->
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<!-- Oracles XA datasource cannot reuse a connection outside a transaction once enlisted in a global transaction and vice-versa -->
<no-tx-separate-pools/>
<!--<track-statements>true</track-statements>-->
<prepared-statement-cache-size>500</prepared-statement-cache-size>

</xa-datasource>


<depends optional-attribute-name="TransactionManagerService">jboss:service=TransactionManager




- PAD = true on jboss-service.xml to make oracle connection work.
- All logs to INFO in log4j.xml
- Web service running on 8080 disabled.
- Both Jboss are connected using mod_jk2 to an Apache 2.0.48 running on the same machine.

I have used the jmx console and I see the getters take long time to execute, specially on varchar2 fields. The pages shows a list of trades. an each line takes 1 second while on jboss 2.4.4 takes 300 ms....

Let me know if you need any more information

guix

[def]

We observed heavy CPU use on startup of 3.2.4 compared to 2.4.x due to some XML schema validation that was re-reading and parsing the schema.
This added a couple minutes to startup time on 2 GHz processor with 1 GB RAM. Stark advised me to patch my copy to remove this validation.

But we had to move to 3.2.4 to avoid a major memory leak in DB connection pooling in 2.4.1, which was crashing the server every couple weeks. So slow startup seemed a small price to pay for increased stability.

This did not seem to affect run-time performance, but then we pre-compile all JSPs rather than compiling on the fly. You could try pre-compiling JSPs to see if performance improves.

[guix]

"dfoulser" wrote:

This did not seem to affect run-time performance, but then we pre-compile all JSPs rather than compiling on the fly. You could try pre-compiling JSPs to see if performance improves.

The problem is on servlets not jsps......

I think the problem is the cache doesnt work. Usin the jmx console its says it has ejbs on the cache ut its executing the sqls anyway while in 2.4 once the beans are on the cache it does not go to the database......

[rimmeraj]

Can you provide a link , or what to patch. For development it seems silly to wait for xml schema parsing

[def]

Posted: Sat Mar 6, 2004 15:04 PM
Post subject: Re: deployment slow on 3.2.3 - how to disable mbean xml.vali

In the performance tuning forum.

[triathlon98]

If the cache does not seem to work, then it may be caused by your PK class. Are you using a custom class as your PK or just int/long/String ?

Joachim

[guix]

"triathlon98" wrote:
If the cache does not seem to work, then it may be caused by your PK class. Are you using a custom class as your PK or just int/long/String ?

Joachim

Integer / String / Long for single primary keys and PK classes for Multicolumn primary keys....
Strange... in 2.4 cahce works nicely with String / Integer / Long prmary Key Classes.....

[guix]

fixed!
looks like jboss does read commit-option parameters on jboss.xml.... change on standardjboss.xml and worked!

Adrian: why this did not work?


<enterprise-beans>
<container-configurations>
<container-configuration extends=
"Standard CMP 2.x EntityBean">
<container-name>CMP 2.x and Cache</container-name>
<commit-option>A</commit-option>
</container-configuration>
</container-configurations>
...

[jcr]

I have been having the same problem with extending of configurations in my JBoss.xml file under 3.2.3. I have found that if I put the config in without the extends, then it seems to override only what I specify.


<container-configurations>
<container-configuration>
<container-name>Standard CMP 2.x EntityBean</container-name>
<commit-option>A</commit-option>
<!--insert-after-ejb-post-create>true</insert-after-ejb-post-create-->
</container-configuration>
</container-configurations>

..




Hope this helps.

Jared