Mobicents Performance Guide

First, I must say that the performance with the default values is good. You can try to change some parameters, but don't expect great improvements.
So, for reference, here are the parameters that have major impact on the performance.

JBoss

You can look at the following wiki page: JBossASTuning. Most of the things there don't apply, but it's always good to have a fast AS.
The most important thing is to remove logs, leaving just what's strictly needed. Check your log config file in $JBOSS_HOME/server/default/conf/jboss-log4j.xml

Mobicents SLEE Core

When building from source, these two parameters in event router can be changed:

• EXECUTOR_POOL_SIZE

  Default value: 313
  
  For every activity is assigned one thread of this poll. That thread will be responsible for execute the events fired on that activity. One thread can be associated with many activities.
  A good size for this poll is a prime number bigger than twice the number of expected concurrent activities. For example, if you have 1000 events/sec fired on the container in different activities, if each event takes 100ms to process (that includes the time spent by the container to set the environment for the event execussion, and remove it after the event execussion), you have 100 concurrent activities. A good size for the poll would be 211.
  The problem with big sizes is that resources are allocated where they are not needed. If the pool is too small the response time can be compromized, since events can only be executed when the executor for the activity is free. If this is not a prime number there is the risk of some executors are responsible for much more activities than others.

  
  

• MONITOR_UNCOMMITTED_AC_ATTACHS

  Default value: true
  
  This flag was introduced to prevent that some transactions rollback. For further information please take a look at Issue #20.
  If you are sure that your services doesn't suffer from this problem you can set this flag to false, wich will give a performance gain of 5%.
  

The code for the event router is located in core/src/main/java/org/mobicents/slee/runtime/EventRouterImpl.java

SIP

These parameters are important if you use SIP Resource Adaptor. In fact, this are all properties for the SIP stack.

• gov.nist.javax.sip.THREAD_POOL_SIZE

  Default value: 64
  
  This thread pool is responsible for parsing SIP messages, from socket messages into objects.
  A small value will make the stack less responsive, since new messages have to wait in a queue for free threads. In UDP, this can lead to more retransmissions. Big pool sizes allocate resources that you don't really need.
  The default value can look a little exaggerated, but please take a look at the next point.

  
  

• gov.nist.javax.sip.REENTRANT_LISTENER

  Default value: true
  
  This flag indicates if the SIP stack listener (in this case its the SIP RA itself) is executed by one only thread, or concurrently by the threads that parse the messages.
  Since the code in the SIP RA has been changed to support concurrency, there is really no reason to change this property.
  

This properties can be override in resources/sipra/sipra.entity.properties

JVM

These notes depend on the JVM used, but should be pretty much standard. These where written with Sun JDK 1.6 in mind, but should apply to >= JDK 1.5 as well.
To pass arguments to the JVM change $JBOSS_HOME/bin/run.conf or $JBOSS_HOME/bin/run.bat, depending on your operating system.

• Garbage Collection

  JVM ergonomics try to select the best garbage collector for you. The default behaviour is to select the throughput collector. The problem of the throughput collector is that have long pauses times, that block the processing of the JVM.
  If you don't expect so much load, you can try to use the incremental, low pause, garbage collector (-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode). SIP apllications can bennefit a lot from it, since it reduces the among of retransmissions.
  
  For more information please read: Garbage Collector Tuning

   

• Heap Size

  Heap size is important because of garbage collection. Having a very big heap can stop you JVM for seconds, to perform garbage collection. Small heap sizes are not desired either, because puts a lot off pressure in garbage collection.

For more information please read: Performance Wite Papper

Operating System

These notes are for RHEL, but should apply to other versions of unix.

• Large Memory Pages

  To know more about large memory pages, and how to set them, please visit: Java Support for Large Memory Pages
  
  Setting large memories pages reduces CPU utilization by 5%. Please make sure you pass the option -XX:+UseLargePages and you don't get "Java HotSpot(TM) Server VM warning: Failed to reserve shared memory (errno = 22)" when starting JBoss.
  
  For more information check the presentation given by Andrig Mille on JBoss World: Performance Tuning JBoss Enterprise Application Platform on Linux

   

• Network buffers

  You can increase the network buffers size by ading the follwing lines to your /etc/sysctl.conf file:
  net.core.rmem_max = 16777216
  net.core.wmem_max = 16777216
  net.ipv4.tcp_rmem = 4096 87380 16777216
  net.ipv4.tcp_wmem = 4096 65536 16777216
  Then restart.
  
  You should see improvements in I/O. With SIP, the performance improvement is about 20%. Again, you'll probably don't need it unless you have a very high load.

  
  

  
  

Luis Barreiro - Mobicents QA Team