Suveen Nadipalli's Web Log

GlassFish HA White Paper

Choosing a deployment topology is a difficult task especially when IT departments are bombarded with new requirements and in the middle of economic down turn where finance departments are cutting the down the IT budgets . With server virtualization and enterprise-ready GlassFish software customers can drive down costs by significantly improving utilization of existing assets and by leveraging enterprise features of GlassFish open source software.

If you want to save time and money then take a look at the GlassFish High Availability white paper that I have written along with my other colleagues, which  defines reference deployment configurations with multiple service availability requirements in mind. This white paper provides valuable insights into possible reference topologies that meet a variety of deployment needs from a high availability perspective in a virtualized environment.

Also listen to the GlassFish High Availability in Virtualized Environments Webinar, where we talked about the various reference deployment configurations, high availability performance tunings and best practices. We also talked about the GlassFish performance tunings for Sun Fire T2000 servers.

Posted at 02:59PM Apr 15, 2009 by suveen in Sun  | 

Leveraging Identity with GlassFish and MySQL

Need help on how to configure and tune Sun Identity Manager on GlassFish Application Server using MySQL as the repository, then take a look at the white paper Leveraging Identity with GlassFish and MySQL that I recently published along with my colleagues.

This white paper describes what identity management is, how to install and configure Sun Identity Manager using GlassFish and MySQL. It talks about the GlassFish Application Server tunings and Idenity Manager tunings, in the end it compares the TCO for this solution to other vendors' offerings, customers may save million of dollars over three years by using GlassFish and MySQL. In the tunings section the white paper talks about the GlassFish Application Server tunings that have an impact on the Identity Manager performance and also it talks about the Identity Manager best practices and tunings. At the end of tuning section it show the performance comparison with and with out tunings.

Posted at 11:11AM Apr 13, 2009 by suveen in Sun  | 

GlassFish V2

We have released GlassFish V2 and the commercial version of the Sun Java System Application Server yesterday. There were so many performance improvements made in this release.

We have published a best-in-class performance results on SPECjAppserver2004. We are the only open source appserver that has published the results on SPECjAppserver2004.

I along with other engineers worked on improving the cluster startup performance and improving the performance of the newly added in-memory replication.

Startup performance is very critical for developers and a crucial factor during the product evaluation. We have made several optimizations and improved the startup time significantly. Take a look at Prashant's blog for more information on what optimization were done and the improved startup performance results.

GlassFish V2 has added a new session persistence type called in-memory replication, which provides high availability and failover capabilities of HTTP sessions and stateful session beans in a clustered environment. This is the first time we are releasing this feature and it is based on robust architecture of JXTA. Setting up in-memory replication is very easy compared to the HADB solution. All you need to do is create a cluster with 2 instances and set the persistence-type to "replicated" under availability-service. Make sure you have turned the availability-enabled to true for your application. We have made several performance optimizations along the way and in-memory replication performs better than HADB. We have done some scalability studies and in-memory replication scales near linearly as you add more instances to the cluster. We still have the HADB solution available in case if some one wants highly reliable session persistence mechanism with 5-9s availability.

More performance improvements are in the works for upcoming releases. Stay tuned ..

Posted at 01:17PM Sep 18, 2007 by suveen in Sun  | 

JavaONE 2007

Me along with other members of our team are giving a Hands On Lab [HOL] on Benchamarking and Profiling Web2.0 applications. If you are interested in learning how to benchmark and tune your Web 2.0 applications, join us on May 8Th @ 5:40 PM

Here are the details:
LAB-4410
Benchmarking and Profiling Web 2.0 Applications for Performance
Tuesday
05/08/2007
5:40 PM -7:40 PM

Posted at 11:54AM May 04, 2007 by suveen in Sun  | 

Application Server on UltraSPARC T1 systems

In my previous blog on application server performance on UltraSPARC T1 systems I talked about the guide lines for disk configuration. If you found out that disk is a bottleneck, then with application server 8.2, you have the ability to write txlogs to a database. Here are the details:

1) Create a Non Tx connection Pool and JDBC resource
(jdbc resource name must end with __nontx) corresponding to the pool

2) Create a table with the following schema
table name: txn_log_table
Name of the column JDBC Type
LOCALTID BIGINT
SERVERNAME VARCHAR(n)
GTRID VARBINARY
Size of the SERVERNAME should be at least the hostname of the application server machine+10 characters and size of GTRID should be at least 64 bytes.

3) Add the following property to the transaction-service
property name="db-logging-resource" value="jdbc/TxnDS"
Value should be the JNDI name of the JDBC resource configured in the Step 1

Take a look at the blog on IPGE Ethernet Device Driver and TCP Tunable Parameters. It talks about default value, range and when to tune each parameter. IPGE tuning is important for better performance on UltraSPARC T1 systems.

If you haven't tried application server 8.2, you can download and enter to win a Sony PlayStation Portable.

If you have any questions on Java SE, Java EE and Webservices performance post your questions to the performance forum

Posted at 04:22PM Feb 17, 2006 by suveen in Sun  | 

Sun Java System Application Server Performance Tunings On UltraSPARC T1 Chip Multithreading Systems

I want to share sun application server's tunings information on UltraSPARC T1 systems for best possible performance.

Application Server Software Versions :

Sun Java System Application Server 8.2
If you are using application server 8.1 then Patch 119167-02 with Java SE 1.5.0_06 is necessary.

The UltraSPARC T1 processor combines chip multiprocessing (CMP) and hardware multithreading (MT) with an efficient instruction pipeline to enable chip multithreading (CMT). The resulting processor design provides multiple physical instruction execution pipelines and several active thread contexts per pipeline. The UltraSPARC T1 processor was designed to scale well with applications that are throughput oriented and multi threaded in nature, so this is an ideal platform for application servers.

Following are the list of tunings :

Use of FX scheduling class:

It is recommend to put the application server into the FX scheduling class. To do so, find out the process id of the appserver process (ps -ef | grep appserv) and MQ Broker daemon (ps -ef | grep mqbrokerd). For each process id, execute: /usr/bin/priocntl -s -c FX -m 59 -p 59 -i pid process_id_of_appserver.

Disk Configuration:

If your application logs HTTP access requests or are using XA transactions or MDBs, then you will want to follow these guidelines for the disk:

1. Separate the access logs, transaction logs and imq files onto as many disks as possible. If you have two disks, put the XA transaction logs (instance_directory/logs/tx) on one disk and the imq files (instance_directory/imq/instances/imqbroker/fs350) on another. If you have more disks, put the imqbroker txn file on its own disk.
2. If you run with multiple instances of the application server, move the logs of each instance onto separate disks as much as possible.
3. Mount the disk with these options: nologging,directio,noatime.

Network Configuration:

If you are using more than one network interface, then you will need to make sure that all the network interrupts are not going to the same core.

Java VM Tunings :

A number of optimizations have been added to the newly released J2SE 5.0_06 for CMT and for UltraSPARC T1 processors in particular. Also if you find that your application doesn't scale well, try running it with JDK 1.5.0_06 with the -XX:+UseBiasedLocking option, which can help improve the performance of applications with significant amounts of uncontended locking.

Placing Java Heap on Large Pages:

LargePageSizeInBytes requires J2SE 5.0_06 and Solaris 10 HW2. Also when you are setting the heap size make sure that it is a multiple of the large page size.

-XX:LargePageSizeInBytes=256m
-Xmx2560m -Xms2560m

Reduce the default thread stack size:
The default thread stack size can be changed using the -Xss option. Selecting a value such as 256k or 512k will reduce the amount of virtual memory reserved for each Java thread's stack.
-Xss128k

Tune GC Threads:
When running your application, you might need to scale back the number of garbage collection (GC) threads. This obviously depends heavily on the amount of garbage being generated. Too many GC threads can affect the throughput of the system. A good starting point is to set the number of GC threads to the number of cores on the system running UltraSPARC T1 processors.

XX:ParallelGCThreads=N
where "N" is the number of cores

Other JVM tunings:
-server
If appropriate for your environment, disable the security manager by removing the -Djava.security.policy argument from the jvm-options
-XX:+AggressiveHeap

Application Server Specific Tunings :

Thread pools : You want to size the HTTP thread pool as small as possible while still getting good throughput. you also want to size the HTTP acceptor threads to match the machine. Having one acceptor-thread per core is optimal. Even for ORB thread pool, you want to size it as small as possible.

JSP recompilation: turn this off (either in the application's web.xml or in application server instance's default-web.xml)

Change the application server log level to WARNING.

Disable dynamic reloading and autodeploy features.

Turn the access logging off.

Posted at 03:03PM Feb 08, 2006 by suveen in Sun  |  Comments[2]