JBoss AS Performance (with EJB 3.0)

[grdzeli_kaci]

hi all,
i have topic about this on this forum
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=106866

i want performance tuning of jboss application server and my ejb 3.0 project,
there i post my server parameters

1.AS - JBoss Application Server 4.0.4GA
2.Database - Oracle 10G 10.2.0.1
3.EJB - 3.0 Framework
4.OS - SunOS 5.10
5.Sun Server - Memory: 16G phys mem, 31G swap, 4 CPU,

also i have java performance configuration :

JAVA_OPTS="-server -Xmx3168m -Xms2144m -Xmn1g -Xss256k -d64 -XX:PermSize=128m -XX:MaxPermSize=256m
 -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
 -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
 -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -XX:+AggressiveOpts
 -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintTenuringDistribution
 -Xloggc:/export/home/jboss/jboss-4.0.4.GA/server/all/log/gc.log"

maybe i have something incorrect to achieve best performance can anybody help me ?

if JBoss Application Server could persist 1500 - 2000 entities per second, it will be great,
i have mission critical task, on development time i could not define all business requests for my program, already i wrote so large many application using distributed databases and applications, now i have very bad problem - performance.

and also, we (my company and i, i am a developer for this company) are trying to bye JBoss Application Server support "JBoss Enterprise Middleware Subscriptions" but yet we need to assure that we could resolve this problem,

is it possible to resolve this problem?
maybe we could change some configurations for best performance ?
or maybe Is it necessary to bye support to resolve this problem ?


Regards,
Paata.
Magticom L.T.D

[peterj]

A few thoughts:

Having the GC statistics options (such as verbose:gc) on is good if you plan to collect and analyze the statistics. But you should not have them on during production (or even to evaluate the actual performance of your app).

Be aware that UseConcMarkSweepGC is good if you want to guarantee consistent response times. However, it dramatically reduces your throughput. I suggest running both with and without it to see what works best. Considering the heap size you set I don't think you want to suffer through a full garbage, so perhaps having UseConcMarkSweepGC set is best.

The AggressiveOpts option resets a whole set of options (not sure if it resets UseConcMarkSweepGC, I could look at the code but I'm being lazy right now). I recommend testing with and without it, and if you must set it, set it first.

Finally, since every app is different and has different requirements. And each app tends to run on very different hardware, you must spend some time to drive the system, analyze the performance results (including the GC statistics), tweak the settings, and then repeat until you have acceptable performance. I have gone though this cycle for multiple customers, and it takes a significant investment in time and resources. That, of course, is something that cannot be done in a free forum, hence a good reason to buy support.