08 J2EE Perf Best Practices

J2EE Performance Best Practices
08_J2EE_Perf_BestPractices.ppt Page 1 of 58
WebSphere Application Server
Key Tuning Areas
• Web site applications
• Threading Issues
• EJBs
• JVM
• HttpSessions
• Connection pools
• External Performance Issues
• Dynacache
Web Site Application
Apps and Performance
• Application tuning often yields the largest performance gains
• Code profilers help you reduce path length
• Other techniques to resolve runtime performance issues
• Thread dumps
• Java heap profiles
• HttpSession sizing
Common Pitfalls
• Synchronization
• Mishandling of pooled objects
• Indefinite delay
• Multi-threading problems
• JSP Issues
• Common EJB Issues
Synchronization
• Synchronization is required in some cases

• Accessing shared resources (ex: threadpools)
• Problems arise when

• Overused to compensate for weak concurrency skills
• Synchronized code block is too large
• Synchronized code block improperly coded
• “Indefinite wait” inside the block
• Permits starvation
• Globally search Web site applications for synchronization

• Understand and authorize each use
Thread Pools
• Thread pools a good idea for:

• Avoiding thread creation overhead
• Managing number of threads in the system
• Rampant thread creation may crash a server
• Evaluate use of threads carefully

• Would the app run more safely synchronously?
• Are failures handled properly?
• Consider async beans in WAS EE

• TOC for customer may be less in the long run
Proper Thread Pool Management
• Obtaining and Returning pooled threads must be synchronized

• Keep sync’d code extremely small
• Min/Max thread pool size recommended

• “Grow-by” parameter also desirable
• Place parameters in an external source for tuning
• XML file, resource bundle
• Read at initialization
• Fancy pools provide servlet admin interface
• DO NOT WAIT INSIDE THE POOL!

• For example, if the pool needs to add new connections
• Better to throw soft failure and retry
Pooled Object Etiquette
• Return pooled resources quickly!

• Do not make the return part of cleanup process
• After finished, return the object
• Relieves requester queue at peak times
• Cleanup the resource appropriately

• close() the database statement
• Do not return running threads to the threadpool
Indefinite Delay
• Avoid indefinite waits inside the web application
• True for
• Database requests
• Launched threads
• Remote requests of any kind (HTTP sockets, etc.)
• Bound wait with timeouts

• Threads: join(100) instead of join()
• JDBC calls: stmt.setQueryTimeout() if supported
• Place all timeout values in an external properties file

• Essential for site tuning later
Indefinite Delay Exceptions
• What if the servlet really needed the data?
• If the request times out, return a specific exception

• Ex: “Non_Responsive_Exception”
• Code servlet to handle this error path

• Select appropriate error JSP or similar action
• Better to return empty-handed than stall the site
• Prepare applications for eventuality of a remote outage!
Other Notable Performance Issues
• Avoid excessive logging

• Avoid servlet.log()
• Build log Strings after confirming logging is enabled
• Avoid bean.instantiate()
• Initiates disk I/O to check for bean contents
• new the bean instead
• Avoid “+=“ to build Strings

• Use JSPs; don’t build HTML in servlets
• Use J2EE datasources whenever possible
Other notable performance issues
Turn off auto reloading for production and test

systems
Avoid the “SingleThreadModel” for servlets
Cache sharable values in instance variables

¾ Example: Datsources, EJB Home Interfaces
¾ Obtain within init() method; faster than built-in
caching
JSP Issues
• Avoid creating unnecessary HTTPSession objects

• <%@ page session=“false”%>
• Other servlet best practices apply to JSP scriptlets
• Keep scriptlet use to a minimum

• Taglibs where appropriate
• Better for maintainability
• Also:
• Consider changing JSP reload intervals
Canonical Servlet
• Avoid canonical servlets

• One large servlet controlling the entire website
• For each servlet

• Handle logic to select between 2 or 3 JSPs
• Pull together dynamic data to feed the JSP
• Handle common error conditions
• Also avoid
• Fine-grained servlet modeling (opposite problem)
• JSP-only solution
• Difficult to maintain dispersed logic
Flow Examples
• Small servlets control a few pages

• Work with group of servlets
• Easier to extend website
Servlet StockQuote.jsp • Add servlets
SymbolResult.jsp
NotFound.jsp
UnKnownError.jsp MyStatement.jsp
StockQuote.jsp
• Large servlet controls many pages

SymbolResult.jsp
• No logical relationship between pages Errors.jsp
• Code path is very long
• Performance issue
• Difficult to extend site MyAccount.jsp Servlet
• Must carefully modify huge servlet
TradeHistory.jsp
Key Tuning Areas
• EJBs
• JVM
• HTTPSessions
• Dynacache
Threads
How Many?
• Each container controls its own thread pool

• Default size is 10 threads minimum, 50 maximum
• Only WAS interacts with these threads
• Threads launched within servlets do not use this pool!
• More is often less

• More threads means more overhead
• JVM time wasted on context switching
• Avoid unbounded growth

• EJB container settings?
Threads
Funnel Queue
• The application server contains a series of pools

• Each pool contains a wait queue
• Queuing reaches from the HTTP Server to backend DBs
• An example of a 150 > 20 > 10 Funnel Queue
150 20 10
Listeners Q Threads Q Connections
u u
e e
u u
e e
HTTP Server Application Server Datasource
Threads
Funnel Queue (cont’d)
• Processing at each level reduces pool demand downstream

• Example: Some HTTP listeners return static content
• Example: Servlets require significant String processing
• Also expedient to have some demand queued for quick entry
150 20 10
u u
e e
u u
e e
Threads
Frozen Web site
• Threads may stall if a remote resource goes down

• Downstream queues begin to fill up
• Servlet engine, HTTP Server
• Eventually Web site cannot respond to static HTML requests
150 20 10
u u
e e
u u
e e
Key Tuning Areas
• EJBs
• JVM
• HttpSessions
• Dynacache
EJB 2.0 Performance
700 668
625
600 536
500
Throughput-Request/sec
400 EJB 2.0 Local Interface

Call-by-Reference
300
EJB 2.0 Remote
200
100
0
Local Interfaces S EJB EJB
Servlet session entity
3000 2687 2675
2500
2000 Option 'C'

1500 Option 'B'
982 975 Option 'A'
1000 Life-time-in-Cache
500
0
EJB Caching Options
EJBs
Use a Façade Bean
• Avoid calling multiple Entity Beans within a servlet

• Txn boundary created at each call for remote calls
• Performance expensive
• Use a façade bean instead

• Stateless session bean interacts with multiple EJBs
• Local txn boundary spans all calls
• Within the Stateless session bean
• Assumes SSB and Entity Beans in same container
• Return data as a regular databean to calling servlet
• Performance and architectural benefits
• Co-locate EJB and Web containers for best performance
EJBs
Granularity
• Avoid extremely fine-grained EJB models
• Potential to create dozens/hundreds of objects on each call
• Creates issues with JVM memory, container sizing, etc.
• Better to use a more granular model

• Create a few objects per call
• Reduces burden on memory, CPU
• More maintainable architecture
EJBs
Cache Sizing
• Container cache holds bean in use by the application
• Sizing the cache important for best performance
• Tuning guide recommendations

• Entity Beans per txn * expected concurrent txns
• Add active session bean instances
• Remember, EJBs sometimes long-lived

• Entity bean Option A, Lifetime-in-cache caching
• Stateful Session beans
• Stateless Session bean pool
EJBs
Passivation
• Passivation writes bean contents to hard disk
• Hard disk I/O very expensive

• Inefficient at high volumes
• Size the bean container cache properly
• Remove Stateful Session beans as soon as possible

• ejb.remove() method
Key Tuning Areas
• EJBs
• JVM
• HttpSessions
• Dynacache
JVM
JVMs and Performance
• JVM sizing important for performance

• Size vs. Garbage Collection time tradeoffs
• Application quality impacts JVM efficiency
• Key JVM issues

• Heap size
• Garbage collection
• Memory leaks
• Memory usage
JVM
Heap Size
• Moderate heap sizes work best
• -Xmx=512M for WAS
• -Xmx=768M for WP
• 1 GB heaps supportable on most multiprocessor boxes
• Minimum heapsize
• Production systems set –Xms lower than –Xmx
• Gives headroom for emergencies
• In theory, results in more efficient object table
• “Burst” testing requires –Xms=-Xmx
• Larger heaps feasible on extremely fast machines

• Also indicates application inefficiencies
JVM
Garbage Collection
• The larger the heap, the longer the GC cycle

• Mitigates benefits of a large heap
• JDK 1.3.1 GC
• Interim gc’s free memory (multi-threaded)
• Compaction cycle for defragmentation
• Single-thread; stops application work
• Frequent GC caused by:

• Inefficiencies in the application
• Excessive object creation (ex: Strings)
• Sometimes occurs at –Xms threshold
JVM
Memory Leaks
• Java applications may still “leak”

• GC only picks up objects without references
• Does the heapsize continue to grow under steady load?

• “Sawtooth” gc pattern has irregular shape
• GC cycles become more frequent
• “Java out of memory” errors in logs
• Some common “leak” culprits

• HttpSession timeout is too long
• HttpSessions contain extremely large objects
• Servlets caching objects in another variable
JVM
Memory Leak Pattern
Key Tuning Areas
• EJBs
• JVM
• HttpSession
• Dynacache
HttpSession
Common Performance Pitfalls
• HttpSession misused by many Web applications

• Impacts performance, scalability, and failover
• Common HttpSession pitfalls:
• Large HttpSession objects
• Poor timeout strategies
• Poor persistence preparation
HttpSession
Large HttpSession Objects
• HttpSession objects live in a memory cache
• Cached shared by every user visiting the server
• Optimal HttpSession size is a few KB or less (approx. 2KB)
• Failure to keep session size small results in:
• Memory overhead
• Application “leaks” under large user volumes
• Poor session persistence performance
HttpSession
Poor Timeout Strategies
• Default HttpSession timeout is 30 minutes

• No end user activity on the site for 30 minutes
• Depending on the site, this time maybe reduced

• Frequent, short visits with little reading time on pages
• Avoid setting too low
• Reaper thread impacts performance
• Give the user the opportunity to logout

• Destroy the HttpSession on logout
• Do not rely on the customer logging out
• Most do not
• Keep this in mind in your testcases as well
HttpSession
Poor Persistence Preparation
• Persistence Session Management transparent to applications

• No special APIs required
• But the code may need special prep for persistence
• Session contents should be

• Small for easy transfer and retrieval
• Serializable
• No thread handles, binaries, etc.
• Meaningful on failover
• Broken into smaller object graphs
• Do not use persistent storage as an extended cache

• Working set of HttpSessions should always be in memory
HttpSession
Persistence (cont’d)
• Large HttpSessions problematic for persistence performance

• Longer network transfer time
• More serialization overhead
• More database storage required
• See InfoCenter for large session storage strategies
• Best strategy is reducing the size of the session data
• Persistent Session Management required for

• HttpSession failover
• Affinity routing in the 3.5.x product only
Key Tuning Areas
• EJBs
• JVM
• HttpSessions
• Dynacache
Datasource
Connection Pool
• Datasource manages the connection pool
• Most servlets spend most of their time munching data

• Datasource pool sized much smaller than web thread pool
• “Funnel” approach
• Keep in mind other users of the datasource

• EJB containers, other servlet containers
• Monitor connection usage via Tivoli Performance Viewer
• Also monitor via database usage statistics
Datasource
Excessive Pool Utilization
• Web containers usually require few datasource connections

• If you see significantly higher utilization
• If you see “waiters” for database connections
• You may have database issues
• Before increasing the connection pool

• Check the query response time
• Get the DBA to check for excessive table scans
• Database may need tuning for Web application
• Pool overutilization usually points to a slow database

• Also may point to network between app server and db
Key Tuning Areas
• EJBs
• JVM
• HTTPSessions
• Dynacache
External Performance Issues
• Tuning doesn’t stop with WebSphere
• Remember systems outside of WAS

• Http Server
• Remote content providers
• Infrastructure
• Server OS
• Network
Http Server
• Http Server needs listeners to serve
• Static HTML, gif, jpegs, etc.
• Dynamic page requests
• Site requires sufficient listeners for these requests
• Listeners are CPU intensive

• Drives up the “System” CPU utilization on Unix
• Tailor listeners to your system’s needs
• Too few listeners results in “failed to connect” messages

• Each user browser may make up to 5 simultaneous connections
• SSL more CPU intensive

• Consider HTTP Server on separate machine; SSL accelerator
Http Server
IHS Key Parms for Unix Systems
• MaxClients
• Maximum number of listeners Http Server will start
• 150 – 250 works well for most sites
• StartServers
• Listeners started at Http Server startup
• MaxSpareServers
• Maximum unused listeners Http Server will allow to live
• Set to MaxClients when in doubt
• MinSpareServers
• Http Server tries to keep this many unused listeners alive
• Set to StartServers when in doubt (will not exceed MaxClients)
Http Server
Other IHS Unix Parms
• HostnameLookups
• Http Server can do a DNS lookup on incoming address
• Extremely time intensive – do not use!
• Recommend: HostnameLookups off
• LogLevel
• Keep logging at a minimum to reduce overhead
• Do not insert tags or processing during runtime
• Use post-processing tool
• Recommend: LogLevel error (or lower)
• KeepAlive
• Useful for sites with lots of static content
• Maintains connection for extended time to reduce setup overhead
• KeepAliveTimeout should be set reasonably low
Http Server
Windows
• IHS works differently on Windows platforms

• “Threads per child”
• IIS more commonly used

• Very different operation model
• Key parms
• “Number of Hits Expected per Day”
• Set to “More than 100000”
• “Listen Backlog”
• A waiting queue inside IIS
• Sometimes results in dropped connections in NT
• Can go as high as 200
• See WAS tuning guide

• Latest parms
• Recommended settings
Http Server
Linux Considerations
• IHS Listeners
• Sometimes hang after handling large number of requests
• Require recycling for Linux
• Set the MaxRequestsPerChild parameter in httpd.conf
• Disabled by default (“0” value)
• Try 5,000 instead
• Set high for other Unix platforms
• Listener recycling not required for these platforms
Databases
• Databases often tuned for other types of applications
• Require new indexes to support Web applications
• Tuning for increased request volumes
• Memory buffers
• Maximum connections
• Sum of datasource connection pool max sizes
• May result in licensing issue
• Consider hardware changes/upgrades
Databases
Hardware
• Databases
• Tend to be I/O rather than CPU bound
• CPU I/O Wait time higher than WAS systems
• Will existing platform support increased traffic?
• Improve performance by speeding up DB I/O

• Add disk platters to reduce disk latency
• Database “striping” across the platters
• Logs, data
• DB2 “native” file writing
• Bypasses OS file system
• Use where appropriate
• Disk buffering at the hardware level
Databases
Prepared Statement Cache
• Whenever possible, use prepared statements

• Dynamic SQL calls
• Prepared Statement calls
• Configure WAS prepared statement cache

• PrepStmtCache > diffPrepStmts * min(concurrent user threads, connectionPoolSize)
• See documentation for how to set various WAS versions
• 20% performance savings in some cases
• Monitor via Tivoli Performance Viewer and adjust as needed

• If “cache ejections” value > 0, increase cache size
Server
OS Settings
• Check settings for

• TCP/IP
• Solaris boxes always require TCP/IP adjustment
• System file handles
• Refer to the Performance Redbook for details

• Settings are OS specific
Server
When to Clone?
• Large n-way server with plenty of memory
• Good response time and relative throughput

• Do not add clones if infrastructure under strain
• Example: High Database utilization
• Example: Network bandwidth full utilized
• One JVM doesn’t drive the CPU to saturation
• One JVM has insufficient memory to support the site

• Example: Large HttpSessions
• Best determined by experimentation

• Add clone, add load, measure results
• Throughput increases, CPU utilization increases
• Response time remains constant
Network
• Easy to clog, hard to monitor
• Best to plan network capacity up front

• Validate plan with actual page sizes
• Use network protocol analyzers, file transfers to monitor
• Much more on network capacity planning coming up
Key Tuning Areas
• EJBs
• JVM
• HttpSessions
• Dynacache
Dynacache
• WAS 4.x/5.x feature
• Allows administrator to define cacheable dynamic content

• Cache
• JSP/servlet ouput
• Commands
• WebServices
• Also flush cache to refresh, as required
• Cache resides inside WAS or

• Pushed out to EdgeServer
• Cache keys include:

• URL only
• URL + parameter values
• URL + parameter values + session id
• others
Summary
• Many potential tuning points in the WAS system

• Application tuning usually produces best results
• But not always
• Important thing is to find the bottlenecks in order of severity
• Your system is only as fast as the slowest component
Shameless Plug
ISBN: 0201844540
Available at fine eTailers,
Brick and Mortar stores,
and PubOrder (IBM)!

08 J2EE Perf Best Practices

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

08 J2EE Perf Best Practices

Hochgeladen von

Copyright:

Verfügbare Formate

J2EE Performance Best Practices

• Web site applications

• External Performance Issues

• Application tuning often yields the largest performance gains

• Code profilers help you reduce path length

• Other techniques to resolve runtime performance issues

• Java heap profiles

• Mishandling of pooled objects

• Common EJB Issues

• Synchronization is required in some cases

• Problems arise when

• Globally search Web site applications for synchronization

• Thread pools a good idea for:

• Evaluate use of threads carefully

• Consider async beans in WAS EE

• Obtaining and Returning pooled threads must be synchronized

• Min/Max thread pool size recommended

• DO NOT WAIT INSIDE THE POOL!

• Return pooled resources quickly!

• Cleanup the resource appropriately

• Avoid indefinite waits inside the web application

• Bound wait with timeouts

• Place all timeout values in an external properties file

• What if the servlet really needed the data?

• If the request times out, return a specific exception

• Code servlet to handle this error path

• Better to return empty-handed than stall the site

• Prepare applications for eventuality of a remote outage!

• Avoid excessive logging

• Avoid “+=“ to build Strings

• Use J2EE datasources whenever possible

 Turn off auto reloading for production and test

 Avoid the “SingleThreadModel” for servlets

 Cache sharable values in instance variables

• Avoid creating unnecessary HTTPSession objects

• Other servlet best practices apply to JSP scriptlets

• Keep scriptlet use to a minimum

• Avoid canonical servlets

• For each servlet

• Small servlets control a few pages

• Large servlet controls many pages

• Web site applications

• External Performance Issues

• Each container controls its own thread pool

• More is often less

• Avoid unbounded growth

• The application server contains a series of pools

• An example of a 150 > 20 > 10 Funnel Queue

• Processing at each level reduces pool demand downstream

• Also expedient to have some demand queued for quick entry

• Threads may stall if a remote resource goes down

• Web site applications

• External Performance Issues

400 EJB 2.0 Local Interface

2000 Option 'C'

• Avoid calling multiple Entity Beans within a servlet

• Use a façade bean instead

• Performance and architectural benefits

• Co-locate EJB and Web containers for best performance

• Avoid extremely fine-grained EJB models

• Potential to create dozens/hundreds of objects on each call

• Creates issues with JVM memory, container sizing, etc.

• Better to use a more granular model

Turn off auto reloading for production and test

Avoid the “SingleThreadModel” for servlets

Cache sharable values in instance variables