Jboss tuning Tips

18 Jul

Remove the unused connecters:

JBoss comes with various connecters support. e.g HTTP,AJP (mod_jk). It’s important you need to identify what are all the connecters your application using. Remove the all other connecter supports for better resource optimisation.

Tattletale :

Tattletale will recursive scan the directory pass as the argument for Java archives and then build the reports as HTML files.

The tool will provide you with reports that can help you

  • Identify dependencies between JAR files
  • Find missing classes from the classpath
  • Spot if a class/package is located in multiple JAR files
  • Spot if the same JAR file is located in multiple locations
  • With a list of what each JAR file requires and provides
  • Verify the SerialVersionUID of a class
  • Find similar JAR files that have different version numbers
  • Find JAR files without a version number
  • Find unused JAR archives
  • Identify sealed / signed JAR archives
  • Locate a class in a JAR file
  • Get the OSGi status of your project
  • Remove black listed API usage
  • And generate the same reports for your .WAR and .EAR archives

By this reports you could easily find out whether your application packaging structure is clean an well structured or not

Caching EJB entries:

If your application involved with EJB, then try this .To avoid roundtrips to the database, you can use a cache for your entities.

<property name="hibernate.cache.use_second_level_cache" value="true" />
            <property name="hibernate.cache.use_query_cache" value="true" />

With caching enabled:

  • If you persist an entity (that has caching enabled) to the database via the entity manager the entity will also be added to the cache. Subsequent requests to fetch the entity, with this id, will be retrieved from cache and thus will save a database trip.
  • If you update an entity (that has caching enabled) and save the changes to the database via the entity manager the entity will also be updated in the cache.
  • If you remove an entity (that has caching enabled) from the database via the entity manager the entity will also be removed from the cache.

To enable cache refer here

  Tuning JVM:

  • TuneVMGarbageCollection or Tune JDK 5 Garbage Collection for your machine and memory size
  • Use a 64 bit machine and 64 bit VM so that you can use large heap sizes, larger than 2-4GB typically.  64 bit support is available on all recent SPARC/Solaris boxes running Solaris 9 or later, Itanium with JDK 1.4, or JDK 5 on Linux x64.
  • DO NOT USE -d64 (64-bit) if you do not use ABOVE the maximum 32 bit heap space (2-4 GB of heap). Using 64 bit addressing requires MORE memory to do the same amount of work and provides no advantage for applications that do not need this much memory.
  • Avoid extra large heaps but avoid extra small heaps. (We cannot tell you what qualifies because it depends on what you’re doing). This affects generational garbage collection and total time to scan the heap. It is difficult to tune a small heap effectively (even if your app only uses 200MB, if you’re using parallel garbage collection + CMS, then you’re going to need well above 512MB). Oversize heaps spend needless time scanning memory for garbage collection.
  • Avoid the Sun 1.4 VM.  JDK 5 is VASTLY better especially in the area of garbage collection.
  • Use the -server option but use either of -XX:ThreadStackSize=128k (Solaris) or -Xss128k (every other platform). On Solaris -Xss128k does nothing (you can only set LARGER thread stack sizes). This allows you to create more threads by using less memory per thread but might result in blown stacks with extremely recursive code.  Still, 128k stack is still nothing to shake a stick at.
  • You really need to understand generational garbage collectors to tune this properly and you really have to do load testing (OpenSTA, JMeter, etc) to know for sure.
  • You really should use a multi-processor machine with more than 2 processors and use various parallel and concurrent garbage collection options (we cover this in Advanced JBoss Training hint hint) for maximum performance and high garbage collector throughput. However, you really need to understand how garbage collection works to tune this well.  JDK 5 is mostly self-tuning.
  • JDK 1.4’s default NewSize is not a good guess. Bad rule of thumb: < 20% is a good NewSize. Above 20% is dangerous due to a nasty JDK bug which can cause it to psychotically run all full garbage collections and never unsuspend or free up enough memory. JDK 5 does not seem to exhibit this bug and seems to pick more sane defaults.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: