Monday Oct 13, 2008

WebSphere Application Server and T5440

Today, we are announcing the next generation server based on UltraSPARC T2 Plus processor and this server happens to be a monster in terms of performance. It can consolidate a lot of servers in a single box providing the similar combined throughput. For the server details and other blogs related to this server I suggest you to visit T5440 Blog index(
In this blog, I summarize the performance of IBM WebSphere Application Server (WAS)  on T5440. To test and benchmark the performance, I use the most recent release WAS v7, that is based on Java EE 5 spec and JDK 6, with numerous features and performance enhancements. As I said earlier that this new Sun server is a monster in terms of performance, the WAS software set up and configuration require some planning and appropriate allocation of the system resources.   When you do the psrinfo(1M) command on this server, it will report to you that the system has 256 "processors".  This means that the processing power of this system far exceeds the software scalability of a single instance of the Application Server's. Thus, you will need multiple instances of WAS to drive the system to its full utilization.  Solaris Containers provides the most efficient way to accomplish such configuration as Solaris Containers provides process space isolation among different WAS instance as well as allocating proper system resources.
For maximizing the utilization of the system, I configured the environment as follows.

  • I created 7 Solaris Containers, allocated 32 processor threads to each of the 6 Containers, and allocated the remaining processor threads for the other container and the global zone.  Then, I used the following WAS configuration:

  • initialHeapSize="2500" maximumHeapSize="2500"

  • -server -Xmn2048m -XX:+AggressiveOpts -XX:+UseParallelGC -XX:ParallelGCThreads=16 -XX:+UseParallelOldGC -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XML11Configuration

  • Disable the PMI feature.

  • Disable the System.out logging from the admin console if you want you can do the same by editing the config file. by editing the trace service like - startupTraceSpecification="\*=info:SystemOut=off"

  • DynaCache - The DynaCache was used for this benchmark so the default size of the cahce was set to 2000 which wasn't enough for this test which can be adjusted accordingly based on the application need as I set it to 3000.

  • For thread pool tuning the only thing that was relevant in this benchmark was tuning the WebContainer thread pool right so I did set it to 80 and which was more that enough and I think It can be scaled down a bit but havn't tried.

  • Database connection pool was set it to same value as WebContainer pool and set the min and max to the same value.

For database I did not want to run into the network/disk contention so I created the DB in /tmp and I had to use two databases for this purpose. This was just to eliminated the Database configuration headaches and just measure the App Server machine scalability. These database were connected point-to-point with App Server box and the App Server instances were using the point-to-point connection for the DB.
This resulted in getting to 1.8X scalability of its predecessor system(T5140) in terms of throughput(which is measured for this benchmark in terms of requests served per second or more commonly known as req/sec).
So In nutshell if you are looking for another system to consolidate your WebSphere deployment with 1.8X throughput capacity of earlier UltraSparc T2 plus system then T5440 may be just the right system for you.

Tuesday Oct 09, 2007

UltraSPARC T2 and WebSphere Application Server

As Sun continue to provide breakthrough multi-core technology and systems based on that you are going to have your hands on this new cool server very soon. As you already may know that its predecessor(Sun Fire T2000) has established itself as the best J2EE App Server Platform (In fact it dominates the other area too but I will leave that to my colleagues to comments on). The details from SPEC web-site are here for your reference:
BEA WebLogic Server SPECjAppServer2004 result on Sun Fire T2000
IBM WebSphere Application Server SPECjAppServer2004 result on Sun Fire T2000
Oracle Application Server SPECjAppServer2004 result on Sun Fire T2000
Sun Java Application Server SPECjAppServer2004 result on Sun Fire T2000

Now you are going to see the next generation server named Sun SPARC Enterprise T5120/T5220 and this is going to continue to lead this segment and other as well. Don't forget to check this blog.

So coming to the point I got my hands on one of these system and did some performance study of WebSphere Application Server V 6.1 and I found these systems to be very impressive. The results of our tests shows that it can give you double the performance of T2000. Due to limitation of 4GB of address space for 32-bit process and the App Server's own scalability, I think none of the App Server will be able to scale and fully utilize this system. So I used multiple instance to maximize the system usages. As the software remains the same the tuning and tuning recommendations are not going to change.

Here is what I have done with my WebSphere Application Server to get best out of this system:

Thread Pools:
ORB: 39/39
Web Container: 47/47
Default: 20/20

EJB Cache: 60000 (previously recommended setting on my blog would be ok too).

JVM Settings:
Heap : 2300-2600
-server -XX:NewSize/-XX:MaxNewSize 1/3rd of Heap
-Xss128k -XX:LargePageSizeInBytes=256m -XX:+AggressiveOpts
-XX:+UnlockDiagnosticVMOptions -XX:-EliminateZeroing -XX:+UseParallelGC
-XX:ParallelGCThreads=16 -XX:+UseParallelOldGC

Connection Pool:
Min/Max Connection: 160/160
Statement Cache: 120

Then the usual stuff we do with TCP Connection settings, disabling the performance monitoring framework, setting the keep-alive etc.

Here are few of the setting I put in my /etc/system and which helped a lot for network performance and interrupts distribution:
set ip:ip_soft_rings_cnt = 8
set ddi_msix_alloc_limit = 8

Some of the issues I came across and you should also keep an eye on that:
Use intrstat(1M) and mpstat(1M) to find out how the interrupts processing going on. intrstat will give you the interrupts processing for different devices and which core is handling that and then you can look at the mpstat(btw this is very long so redirect to some files to take a look at it later) which will tell you if it is a bottleneck.
DB Connection – They always originates from whatever is returned by gethostbyname(3NSL) API and thus it may become bottleneck. So I used containers so the result of these API call are different i.e that will hostname(1) of your zone.
Full GC – Keep an eye on full GC and set the New Generation appropriately.

Note: If you are looking for more information on UltraSPARC T2 don't forget to check

Disclosure Statement:
SPEC, SPECjAppServer2004 are reg tm of Standard Performance Evaluation Corporation. Links are from




« February 2017