Server User Manual
Table Of Contents
- Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide
- Preface
- Overview of Enterprise Server Performance Tuning
- Tuning Your Application
- Java Programming Guidelines
- Java Server Page and Servlet Tuning
- EJB Performance Tuning
- Goals
- Monitoring EJB Components
- General Guidelines
- Using Local and Remote Interfaces
- Improving Performance of EJB Transactions
- Use Container-Managed Transactions
- Don’t Encompass User Input Time
- Identify Non-Transactional Methods
- Use TX_REQUIRED for Long Transaction Chains
- Use Lowest Cost Database Locking
- Use XA-Capable Data Sources Only When Needed
- Configure JDBC Resources as One-Phase Commit Resources
- Use the Least Expensive Transaction Attribute
- Using Special Techniques
- Tuning Tips for Specific Types of EJB Components
- JDBC and Database Access
- Tuning Message-Driven Beans
- Tuning the Enterprise Server
- Deployment Settings
- Logger Settings
- Web Container Settings
- EJB Container Settings
- Java Message Service Settings
- Transaction Service Settings
- HTTP Service Settings
- ORB Settings
- Thread Pool Settings
- Resources
- Tuning the Java Runtime System
- Tuning the Operating System and Platform
- Tuning for High-Availability
- Index
Calculating the number of locks
To calculate the number of locks needed, estimate the following parameters:
■
Number of concurrent users that request session data to be stored in HADB (one session
record per user)
■
Maximum size of the BLOB session
■
Persistence scope (max session data size in case of session/modied session and maximum
number of attributes in case of modied session). This requires setAttribute() to be called
every time the session data is modied.
If:
■
x is the maximum number of concurrent users, that is, x session data records are present in
the HADB, and
■
y is the session size (for session/modied session) or attribute size (for modied attribute),
Then the number of records written to HADB is:
xy/7000 + 2x
Record operations such as insert, delete, update and read will use one lock per record.
Note – Locks are held for both primary records and hot-standby records. Hence, for insert,
update and delete operations a transaction will need twice as many locks as the number of
records. Read operations need locks only on the primary records. During refragmentation and
creation of secondary indices, log records for the involved table are also sent to the fragment
replicas being created. In that case, a transaction needs four times as many locks as the number
of involved records. (Assuming all queries are for the aected table.)
Summary
If refragmentation is performed, the number of locks to be congured is:
N
locks
=4x (y/7000 + 2) = 2xy/3500 + 2x
Otherwise, the number of locks to be congured is:
N
locks
=2x (y/7000 + 2) = xy/3500 + 4x
Tuning NumberOfLocks
Start with the default value. Look for exceptions with the indicated error codes in the Enterprise
Server log les. Remember that under normal operations (no ongoing refragmentation) only
half of the locks might be acquired by the client application.
To get information on allocated locks and locks in use, use the following command:
hadbm resourceinfo --locks
Tuning HADB
Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide • January 2009114