1. Overview of GlassFish Server Performance Tuning
3. Tuning the GlassFish Server
Using the GlassFish Server Performance Tuner
Use Pre-compiled JavaServer Pages
Disable Dynamic Application Reloading
Session Properties: Session Timeout
Manager Properties: Reap Interval
Overview of EJB Pooling and Caching
Pool and Cache Settings for Individual EJB Components
Determining the Best Commit Option
Monitoring the Transaction Service
Viewing Monitoring Information
Tuning the Transaction Service
Disable Distributed Transaction Logging
CacheEntries (CurrentCacheEntries / MaxCacheEntries)
Limit DNS Lookups to Asynchronous
File Cache Information (file-cache)
How a Client Connects to the ORB
Controlling Connections Between Client and Server ORB
Monitoring JDBC Connection Pools
Connection Validation Settings
Connector Connection Pool Settings
4. Tuning the Java Runtime System
The transaction manager makes it possible to commit and roll back distributed transactions.
A distributed transactional system writes transactional activity into transaction logs so that they can be recovered later. But writing transactional logs has some performance penalty.
The following topics are addressed here:
Transaction Manager monitoring is disabled by default. Enable monitoring of the transaction service through the GlassFish Server Administration Console by navigating to the Configurations->configuration-name->Monitoring node. Refer to the Administration Console for complete instructions.
You can also enable monitoring with these commands:
set serverInstance.transaction-service.monitoringEnabled=true reconfig serverInstance
To view monitoring information for the transaction service in the GlassFish Server Administration Console, navigate to the server (Admin Server) node and then select the Monitor tab.
The following statistics are gathered on the transaction service:
total-tx-completed Completed transactions.
total-tx-rolled-back Total rolled back transactions.
total-tx-inflight Total inflight (active) transactions.
isFrozen Whether transaction system is frozen (true or false)
inflight-tx List of inflight (active) transactions.
This property can be used to disable the transaction logging, where the performance is of utmost importance more than the recovery. This property, by default, won’t exist in the server configuration.
Most Transaction Service tuning tasks can be performed through the GlassFish Server Administration Console by navigating to the Configurations->configuration-name->Transaction Service node and then following the instructions in the online help. Alternatively, you can follow the instructions in Chapter 19, Administering Transactions, in Oracle GlassFish Server 3.1 Administration Guide.
You can disable transaction logging through the Administration Console or by using the following asadmin set subcommand:
asadmin set server1.transaction-service.disable-distributed-transaction-logging=true
Disabling transaction logging can improve performance. Setting it to false (the default), makes the transaction service write transactional activity to transaction logs so that transactions can be recovered. If Recover on Restart is checked, this property is ignored.
Set this property to true only if performance is more important than transaction recovery.
You can set the Recover on Restart attribute through the Administration Console or by entering the following asadmin set subcommand:
asadmin set server1.transaction-service.automatic-recovery=false
When Recover on Restart is true, the server will always perform transaction logging, regardless of the Disable Distributed Transaction Logging attribute.
If Recover on Restart is false, then:
If Disable Distributed Transaction Logging is false (the default), then the server will write transaction logs.
If Disable Distributed Transaction Logging is true, then the server will not write transaction logs.
Not writing transaction logs will give approximately twenty percent improvement in performance, but at the cost of not being able to recover from any interrupted transactions. The performance benefit applies to transaction-intensive tests. Gains in real applications may be less.
The keypoint interval determines how often entries for completed transactions are removed from the log file. Keypointing prevents a process log from growing indefinitely.
Frequent keypointing is detrimental to performance. The default value of the Keypoint Interval is 2048, which is sufficient in most cases.