Oracle WebLogic Server 10.3 on Sun SPARC Enterprise T5140

Sun recently published a SPECjAppServer(R)2004 benchmark with Oracle WebLogic Server 10.3 on Sun SPARC Enterprise T5140. Click on the following link for the full report with the benchmark results:

SPECjAppServer(R)2004 benchmark with Oracle WebLogic Server 10.3 on Sun SPARC Enterprise T5140


Typical J2EE applications running on WebLogic Server are CPU intensive and are mostly multi-threaded. Given this, customers would see a great performance boost running on Niagara-based systems. A typical e-commerce or a financial application running on WebLogic Server would mostly use CPU and network resources on the server. We recommend running WebLogic Server 10.3 on these servers as it supports Sun Java 1.6.0 and is known to perform and scale well on these servers.

Tuning Parameters for SPECjAppServer2004

The following tuning has been done to get the best performance with SPECjAppServer2004 workload. Since this tuning is optimized for SPEC benchmark specific load, applying the same tuning parameters may not give best results to your work load. Monitor the performance of your systems with your load. Important areas to focus on include system resource utilization, Java Garbage Collection (GC) behavior, WebLogic thread queues, and I/O latency. Once collected and analyzed, then tune the parameters accordingly.

WebLogic Application Server Tuning

Following tuning is applied to the startWebLogic.sh script in your application domain.

  • Use the following option only if you are not running WebLogic Server instances in the Managed Server mode.

-Dweblogic.management.discover=false


  • We recommend setting the SocketReaders to 4 on the Niagara Servers for better throughput based on our benchmarks. You can switch back to 2 or 1 if you do not see any improvements with your workload.

-Dweblogic.SocketReaders=4

[ or -Dweblogic.DevPollSocketReaders=4 ]


  • Enter the number of seconds, that a thread must be continually working before this server diagnoses the thread as being stuck. By default, WebLogic Server considers a thread to be "stuck" after 600 seconds of continuous use.

-Dweblogic.StuckThreadMaxTime=1200

For more information on performance tuning, see the Oracle WebLogic Server Performance and Tuning Guide (http://edocs.bea.com/wls/docs100/perform/).

Sun Java 6.0 Update 6 (1.6.0_06) Tuning

  • Following tuning is applied to the startWebLogic.sh script in your application domain.

  • WebLogic Server 10.3 supports Sun Java 1.6 and can take advantage of some of the performance improvements that have been made into this release.

  • The following options specifically helped take advantage of the fact that there are more hardware threads available on the UltraSPARC T2 processor.

-XX:+UseParallelGC -XX:ParallelGCThreads=8 -XX:+UseParallelOldGC
  • Here's the complete list of options that we used for SPECjAppServer2004 benchmark.

-server -Xms3g -Xmx3g -Xmn1g -Xss128k -XX:+AggressiveHeap -XX:+UseParallelGC

-XX:ParallelGCThreads=8 -XX:PermSize=128m -XX:LargePageSizeInBytes=4m
-XX:+UseParallelOldGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamp

Solaris 10 Tuning

Solaris 10 10/08 supports nxge 10Gbit and 1Gbit as well as the e1000g network drivers. The following system tunings in /etc/system were used during the benchmark:

set ip:ip_soft_rings_cnt = 16

Network Tuning

Both 10Gbit and 1Gbit networks were used. 10Gbit network was used for drivers/clients and 1Gbit to database. F ollowing tuning options can be set permanently in the /etc/rcN.d scripts. Refer to the online documentation: Run Control Scripts

ndd -set /dev/tcp tcp_conn_req_max_q 16384
ndd -set /dev/tcp tcp_conn_req_max_q0 16384
ndd -set /dev/tcp tcp_xmit_hiwat 131072
ndd -set /dev/tcp tcp_recv_hiwat 131072
ndd -set /dev/tcp tcp_naglim_def 1

About Baseline Numbers

The baseline numbers produced by the benchmark used in this study should not be used to compare WebLogic Server with other application servers or hardware running similar benchmarks. The benchmark methodology and tuning used in this study are unique.


Scaling Up

BEA WebLogic Server scales extremely well on the Niagara-based systems as evident by the SPECjAppServer2004 benchmark. Four instances of WebLogic Server was used to scale up on the T5140 server. To increase the capacity you would need to add additional Niagara-based servers.

In a WebLogic environment, increased application load can be accommodated by adding additional instances of WebLogic servers and deploying applications across multiple servers. WebLogic instances can be installed on multiple physical servers, all within a single WebLogic domain. The domains provide for a point of administration and control over multiple instances and are managed through an Administration Server. This horizontal growth pattern allows for an unlimited amount of expansion to accommodate application growth.

WebLogic instances can also be scaled vertically—adding incremental system resources to a single physical server. In a perfect situation, Java applications would scale linearly as additional system resources are added. There are many factors that can affect the scalability of a Java application, including

  • Garbage collection

  • I/O bottlenecks – disk or network

  • Cache – memory latencies

  • Thread synchronization

To ease the limitations of scaling on a single physical server, multiple instances of WebLogic server can be deployed within the single server system. Running multiple WebLogic instances on a machine generally means running multiple JVM’s as well, so this strategy should be balanced with the increase in configuration and maintenance of multiple instances. For more information on deploying WebLogic servers, refer to .BEA’s Overview of WebLogic Server Systems Administration


Staying Up

WebLogic technology provides for the ability to cluster instances for availability (fail-over) and for scalability (load balancing). Multiple WebLogic servers, within a domain, can be set up as clustered servers and would be perceived as a single instance to the client system. The following list of components and services can be configured within a cluster:

  • Servlets and JSP’s - WebLogic replicates HTTP session information within a cluster so that a single node failure would not interrupt a client session

  • EJB’s and Remote Method Invocation (RMI) objects – WebLogic uses replica-aware stubs so that a client accessing an EJB or RMI object through the stub would recognize a failed instance and attempt to use another replica of the object. WebLogic will also load balance the access to multiple copies of EJB’s or RMI objects.

  • Java Messaging Service (JMS) destinations - supports distributed JMS destinations and connection factories within a cluster

  • Java Database Connectivity (JDBC) connections – load balancing is achieved through clustered connection pools. This doesn’t enable failover of connections, but simplifies the process of reconnected after a connection failure.

  • Java Directory and Naming Interface (JDNI) services - provide failover by replication through the cluster wide JDNI tree

BEA WebLogic Server also supports Sun Cluster for those environments that adhere to an enterprise high availability schema. Sun Cluster provides an agent for WebLogic which allows for the failover of resources within a domain.

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> try { _uacct = "UA-8926411-1"; urchinTracker(); } catch(err) {}</script>
Comments:

Post a Comment:
Comments are closed for this entry.
About

user12610453

Search

Top Tags
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today