Jboss Admin Tutorial: Tuning JBoss

Prev   Next

17. Tuning JBoss

17.1. JVM Tuning

  • HotSpot JIT JVM: -server
  • Memory Allocation: -Xms, -Xmx, -Xss

  • GC Avoidance

    • Monitoring: -verbose:gc

      • Frequency
      • Minor vs. Full GC

    • Optimization

      • GC should run as infrequently and as quickly as possible
  • JVM options: http://java.sun.com/docs/hotspot/VMOptions.html

Example: -XX:NewSize=80m -XX:MaxNewSize=80m -Xms400m -Xmx400m -XX:+UseParallelGC -XX:ParallelGCThreads=2

17.2. Tomcat Tuning

  • Tune connectors in server.xml

    • maxThreads + 25% = max
    • minSpareThreads + 5% = normal
    • maxSpareThreads + 5% = peak
  • Remove unnecessary Valves, Loggers, and Connectors
  • Precompile JSPs
  • Turn off "development" mode on jsp handler (servlet) in conf/web.xml
  • Session timeout

JSPs can be precompiled (by developers or assemblers) using Ant’s jspc task.

17.3. RMI Tuning

  • By default JBoss creates a new thread for each RMI request

    • Wasteful and unscalable during spikes
  • Switch to pooled invoker
  • In conf/standardjboss.xml replace all occurrences of: jboss:service=invoker,type=jrmp by jboss:service=invoker,type=pooled

17.4. Log4J Tuning

  • System-wide logging set on DEBUG or TRACE can bring JBoss to a standstill
  • Configured in conf/log4j.xml

  • By default, JBoss uses INFO priority and logs to both CONSOLE and FILE

    • Consider changing the <root> priority to ERROR
    • Consider logging to FILE only
    • Consider using category filters for your own class hierarchies 
<category name="my.package">
  <priority value="INFO"/>
</category>

<root>
  <priority value="ERROR" />
  <appender-ref ref="FILE"/>
</root>

17.5. Tuning Other Services

  • Increase the scan frequency of the deployment scanner (default: 5 secs)
  • Consider setting MinimumSize on [stateless] Session Bean Container pool (conf/standardjboss.xml)
  • Use Hibernate in place of CMP (2.x)

  • Avoid XA connection pools

    • Use JDBC drivers to check on connections

17.6. JMS Tuning

There are quite a few things that affect the overall performance of the JBoss Messaging system:

  • Re-use connections, sessions, consumers, producers

    • Expensive to create
    • Beware of thread-safety though

  • Disable message IDs if you don’t use them via MessageProducer.setDisableMessageID

    • Message size goes down
    • Avoid needlessly generating unique IDs

  • Similarly, disable message timestamps if you don’t need them via MessageProducer.setDisableMessageTimeStamp

    • Message size goes down
    • Avoid needlessly generating timestamps (not much of an overhead though)

  • Avoid ObjectMessage - even though they seem ideal for transporting arbitrary objects

    • Object serialization is computationally expensive
    • Serialized data tends to be verbose, so it’s not transport-efficient
  • Avoid verbose messages (e.g. XML)

  • Avoid over-using message selectors on queues (i.e. single queue with multiple consumers)

    • Instead, use topics with durable subscriptions

  • Avoid AUTO_ACKNOWLEDGE as that requires every message to be acknowledged

    • More overhead
    • More traffic on the wire

    • Prefer

      • DUPS_OK_ACKNOWLEDGE
      • CLIENT_ACKNOWLEDGE
      • Asynchronous Send Acknowledgements
      • Pre-acknowledge mode
      • Batch-acknowledge multiple messages at the end of a transaction

  • Avoid creating temporary message destinations (queues and topics) on-demand

    • Configure them ahead of time
    • At least re-use them

  • Avoid persistent messages

    • Enabled on JBoss by default
    • Persisting to durable storage means a lot more overhead
    • But guarantees reliability!

  • Avoid security

    • Reduces the overhead
    • But you have to trust the environment

17.7. Slimming JBoss

  • Remove services that are not needed
  • Not a huge impact on performance
  • Frees up memory and other resource (like threads)
  • Faster JBoss startup
  • Excellent security practice
  • Breaks Java EE TCK
  • Create a new configuration set (copy of default)

Services that can be trimmed include the following:

  • Mail Service (and libraries)
  • Cache Invalidation Service
  • J2EE client deployer service
  • HAR deployer and Hibernate session management services
  • Hypersonic (provide a different DefaultDS for JMS MQ)
  • JMS MQ
  • HTTP Invoker (RMI over HTTP)
  • Support for XA Data Sources
  • JMX Console
  • JMX Invoker Adaptor (JMX calls over RMI)
  • Web Console
  • JSR-177 for JMX
  • Console/Email Monitor Alerts
  • Properties Service
  • Scheduler Service/Manager
  • UUID key generation
  • EAR Deployer
  • JMS Queue Destination Manager
  • CORBA/IIOP Service
  • Client User Transaction Service
  • Attribute Persistence Service
  • RMI Classloader
  • Remote JNDI Naming
  • JNDI View
  • Pooled Invoker
  • Bean Shell Deployer

For more information see: http://community.jboss.org/wiki/JBoss5xTuningSlimming

Prev   Next
 Home | ToC