JavaBoutique has posted an article with the title "Six Steps to Faster J2EE Apps: Performance Tuning with JSP and Servlets," by Sridhar M S, focusing on the web tier only and on using JSP and Servlets in that tier.

The six tips are:

• Adopt the correct include mechanism: Here, the author focuses on JSP's include facility.
• Use the correct scope in the useBean action: the author is saying that the incorrect scope can eat memory.
• Use the init() method of HttpServlet for data caching: the author uses the example of getting a database connection from JNDI here, which seems like an odd choice
• Disable auto-reloading of servlets and JSPs
• Session management: the author is saying that session management can be expensive, especially if it's not required
• Use gzip compression: one odd aspect here is the author uses gzip compression generated from a servlet directly, through the use of an outputstream, rather than through a filter, which might be considered a more elegant solution.

Some choices - such as the gzip processing and the Datasource caching - seem odd. Further, the author doesn't go into which containers perform in certain ways, nor does he go into measurement of actual performance impact through profiling or GC tuning, and lastly, the author's focus on servlets and JSPs obviously affects what performance tuning elements would be chosen.

What other performance tuning tips or techniques would you consider? How do you develop faster J2EE applications?

In my opinion analyzing application performance for only one layer is a bit odd. In most cases I met - biggest performance gains were in business tier, or on the edge between business and presentation layer. My tips are:

* Cache everything You can. Hit Your business/data layer as seldom as You can
* Offload static content to faster software (for example usually Apache is very good serving static content)
* Use lazy initialization where You can

Artur

You can cache on the web tier too (did you remember PetShop vs. PetStore story?)

Marina
http://www.servletsuite.com

Beware of any J2EE performance tuning advice that does not include empirical results tested on recent JDKs in a variety of Application Servers!

However I do agree that not designing an application will lead to a badly strung together bag of nails. But isn't that stating the obvious?

Use OSCache (http://www.opensymphony.com/oscache) to cache the time expensive parts of your jsp pages.
Use the service locator design pattern to cache your JNDI look ups.

Use the service locator design pattern to cache your JNDI look ups.

ewwww how 2001 of you.

Put a little Spring (http://www.springfoundation.org) in your step and life becomes just that much more pleasant.

-Michael

Use the service locator design pattern to cache your JNDI look ups.

ewwww how 2001 of you. Put a little Spring (http://www.springfoundation.org) in your step and life becomes just that much more pleasant.-Michael

Let's try that again :)
http://www.springframework.org/

Check out this also:
http://www.servletsuite.com/servlets/cacheflt.htm
and
http://www.servletsuite.com/servlets/cachetag.htm

Dmitry

One of the biggest keys is to have at least one person (hopefully involved as early as application architecture) who understands what the "platform" (OS, app server, frameworks) in total is actually doing to service a request. A lot of the major mistakes that I've seen simply boil down to people not realizing _what_ is expensive and _why_.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Shared Memory for Java

Well if you are looking for similar tips then you should really visit: http://www.javaperformancetuning.com

Another source of useful performance tips with regard to performance investigations (and tool) can be found on our website under "Performance Insight" articles:
http://www.jinspired.com/products/jdbinsight/insights.html

The standard 10 step approach to software performance engineering that we base our product around is:

Software Performance Engineering Activities Plan

The 10 fundamental activities of SPE are as follows:

1. Identify sensitivity of the application design to key business factors (forecast, analyze)
Understand the relationship between business factors (number of uses, service calls or incidents per day, peak hour traffic) and computing applications.

Activities
• Identify Volumes: Users, Number of Transactions, Number of Records, Resource Consumption
• Identify Events: Expected cyclic fluctuations, Rate of Growth

Business factors form the context for other SPE activities. Identifying them early in the development process is important as it establishes when and how often it will be used and how its intended usage is related to business factors.

Planning: Week 1

2. Specify business priorities and performance objectives
Set quantifiable measurable performance objectives then design (deployment topology) with such objectives in mind.

Activities
• Work with users to establish specific performance goals that will drive design, monitoring and tuning efforts.
• Understand the mix of update transactions, decision support queries, reporting and other types of application processing does the server handle.
• Assess whether current performance levels are acceptable.
• Determine priorities. Reduce response times? Increase transaction throughput? Time to deliver? Cost?
• What trade offs can be made for different transaction types and users?
• Determine budget constraints for hardware improvements?

Planning: Week 1

3. Evaluate application, database and system design alternatives
Create an architecture that permits growth using shared resources efficiently and meeting application response times. The design activity must address 3 performance goals: meet performance objectives, conserves resources, and accommodates growth.

Activities
• Databases: larger and more complex
• Users: more users online
• Transaction rates: higher and prolonged peak business periods
• Data analysis: More complex data analysis
• Networks: Linking between LANS and WANS

Planning: Week 1
 
4. Summarize application performance profiles
Collect information about the performance characteristics of an application. Application (users groups / scenarios) performance profiles characterize the workload at three distinct levels of detail: workload, application area and transaction type.

Activities: JXInsight
• Identify workloads: aggregate all resource consumption into a single business activity
• Identify application areas: partition the resource consumption at the application level (console, integration, web)
• Identify transaction types: characterize the workload as individual business transactions

Planning: Week 2-3

5. Predict performance on target platform
Create queuing models for application simulation. Perform full scale benchmarks.

Activity
• Collect Published Vendor Measurements
• Catalog Rules of Thumb (Product Specific)
• Performance Modeling
• Simulation
• Hardware & Software Component Benchmarking

Planning: Week *

6. Monitor ongoing software performance (measure, observe)
Collect performance metrics across important tiers and technology layers.

Activities: JXInsight
• Level 1: Continuous, low cost exception monitoring
• Level 2: Regular, targeted performance tracking
• Level 3: Occasional, focused performance audit
• Build application, resource and component catalog detailing resources used by applications, resource used by software components, software components used by applications…
• Instrumentation of systems to enable measurement and analysis of workload scenarios, resource requirements and performance goal achievement.

Planning: Week 2-3
 
7. Analyze observed performance data (review)
Observe relationships among performance variables, detect trends, and identify performance problems and their likely causes.

• Activities: JXInsight
• Baseline: Record performance statistics under normal operation
• Trend Analysis: Detect relationships among measured variables and trends over time
• Identify Important Measurements: The absence of an obvious pattern during testing or production monitoring with increasing loads indicates that variables important to performance are not being monitored.

Planning: Week 4-6

8. Confirm performance expectations (verify, validate, corroborate)
Perform frequent execution of formal monitoring (Load/Stress) and informal monitoring (User Experience) tests.

• Activities
• Create load testing suites and representative lab environments
• Create database population scripts to replicate the product environment
• Execute Automated Load and Stress Tests
• Involve users in User Experience Testing

Planning: Week 4-6

9. Tune application or system performance (optimize)
Improve aspects of system performance such as database physical design (partitioning, clustering, and indexing), Java process tuning (clustering, loading balancing, and memory heap sizing), and client usage (OLAP versus OLTP).

Activities: JXInsight
• Workload: Minimize the total processing load
• Efficiency: Maximize the ratio of useful work to overhead
• Locality: Group-related components based on usage
• Sharing: Share resources without creating bottlenecks
• Parallelism: Use parallelism when the gains outweigh the overhead
• Trade-off: Reduce delays by substituting faster resources

Planning: Week *

10. Manage ongoing system capacity (plan capacity)
Plan to deliver sufficient computing capacity to maintain acceptable performance as workloads grow and change. For both SPE and capacity planning the goal is to maintain acceptable performance levels in the face of change. For optimal system performance the data storage, network communication, and processing demands imposed by the business workload must be matched with the capacities of the hardware and software resources that make up the system. The previous activities will help in identify peak projected workloads.

Planning: Week *





Regards,

William Louth
JXInsight Product Architect
JInspired

http://www.jinspired.com

I take issue with the first piece of advice in the article:

The include directive is better and faster than the include action, because the page does not get compiled during run-time and hence does not require any server side processing — except the delivery of the page to the client. If your file does not change often, or if it is not a dynamic page, use include directive to improve performance.

The include directive is not always better. In fact, my experience is just the reverse. Using the include directive means that the included code is added to the compiled class for every JSP. The compiled JSP class must be held in RAM, so the include directive can be very wasteful of system memory.

Also, the include directive means your JSP will not be automatically updated when the included file is changed. You must touch all the including JSP as well, which is a major pain for application maintenance.

Besides, for most systems, include directive vs. include action has only a trivial impact on performance compared to issues like caching.

I take issue with the first piece of advice in the article:

The include directive is better and faster than the include action, because the page does not get compiled during run-time and hence does not require any server side processing — except the delivery of the page to the client. If your file does not change often, or if it is not a dynamic page, use include directive to improve performance.

The include directive is not always better. In fact, my experience is just the reverse. Using the include directive means that the included code is added to the compiled class for every JSP. The compiled JSP class must be held in RAM, so the include directive can be very wasteful of system memory.Also, the include directive means your JSP will not be automatically updated when the included file is changed. You must touch all the including JSP as well, which is a major pain for application maintenance.Besides, for most systems, include directive vs. include action has only a trivial impact on performance compared to issues like caching.

I agree. The author states that the include is better in performance because it doesn't have to be compiled!!

Well, here is the whole truth:

- A.jsp static includes B.jsp
At translation time only one .java file (servlet) is created containing both the contents of A.jsp and B.jsp in the service method. So one .java file is compiled once. Upon subsequent requests, there is no translation or compilation.

- A.jsp dynamic includes B.jsp
At translation time two java files (servlets) are created - one for each JSP, containing the respective contents in the service methods. So two java files are compiled once. A, then calls a method on B, to include the content generated by B. This method call (on the call stack) is the only extra thing that happens on each request.
-------------------------------------

How must difference in performance cost can there be, with one more method call on stack... vs N more lines of code in the same java class/method?

Plus you get the benefit of hot deployment of updated JSPs (at least on development machines).

I take issue with the first piece of advice in the article:

The include directive is better and faster than the include action, because the page does not get compiled during run-time and hence does not require any server side processing — except the delivery of the page to the client. If your file does not change often, or if it is not a dynamic page, use include directive to improve performance.

The include directive is not always better. In fact, my experience is just the reverse. Using the include directive means that the included code is added to the compiled class for every JSP. The compiled JSP class must be held in RAM, so the include directive can be very wasteful of system memory.Also, the include directive means your JSP will not be automatically updated when the included file is changed. You must touch all the including JSP as well, which is a major pain for application maintenance.Besides, for most systems, include directive vs. include action has only a trivial impact on performance compared to issues like caching.

I agree. The author states that the static include is better in performance because it doesn't have to be compiled!! Well, here is the whole truth:- A.jsp static includes B.jspAt translation time only one .java file (servlet) is created containing both the contents of A.jsp and B.jsp in the service method. So one .java file is compiled once. Upon subsequent requests, there is no translation or compilation.- A.jsp dynamic includes B.jspAt translation time two java files (servlets) are created - one for each JSP, containing the respective contents in the service methods. So two java files are compiled once. A, then calls a method on B, to include the content generated by B. This method call (on the call stack) is the only extra thing that happens on each request. -------------------------------------
How must difference in performance cost can there be, with one more method call on stack... vs N more lines of code in the same java class/method? Plus you get the benefit of hot deployment of updated JSPs (at least on development machines).

One interesting point about GZipping content is which layer will be doing it.
 Usually the layer handling the SSL ecnryption will be the same doing the GZip encription: in this case GZip is usually convenient at least over HTTPS pages since GZip compression will reduce the amount of data to be compressed and the GZip algorithm is way much faster then SSL encryption.

 Another interesting lesson we leaned by experience is that design-for-cachability is much more effective and much less error-prone then design-for-performance or (even worse) late time optimization: here however you should have at least a basic understandig of you application's usage profile, otherwise you won't simply know how and what to cache