Servlet and JSP performance tips

http://www.ddjembedded.com/resources/articles/2001/0112g/0112g.htm
Balancing Network Load with Priority Queues (Page last updated December 2001, Added 2002-02-22, Author Frank Fabian, Publisher Dr. Dobb's). Tips:

Web hits should cater for handling peak hit rate, not the average rate.
You can model hit rates using gaussian distribution to determine the average hit rate per time unit (e.g. per second) at peak usage, then a poisson probability gives the probability of a given number of users simulatneously hitting the server within that time unit. [Article gives an example with gaussian fitted to peak traffic of 4000 users with a standard deviation of 20 minutes resulting in an average of 1.33 users per second at the peak, which in turn gives the probabilities that 0, 1, 2, 3, 4, 5, 6 users hitting the server within one second as 26%, 35%, 23%, 10%, 3%, 1%, 0.2%. Service time was 53 milliseconds, which means that the server can service 19 hits per second without the service rate requiring requests being queued.]
System throughput is the arrival rate divided by the service rate. If the ratio becomes greater than one, requests exceed the system capability and will be lost or need to be queued.
If requests are queued because capacity is exceeded, the throughput must drop sufficiently to handle the queued requests or the system will fail (the service rate must increase or arrival rate decrease). If the average throughput exceeds 1, then the system will fail.
[Note that Java application servers often do not show a constant service time. Instead the service time often increases with higher concurrency due to non-linear effects of garbage collection].

http://www.javareport.com/html/from_pages/article.asp?id=252
Detailed article on load testing systems (Page last updated January 2001, Added 2001-01-19, Author Himanshu Bhatt, Publisher Java Report). Tips:

Internet systems should be load-tested throughout development.
Load testing can provide the basis for: Comparing varying architectural approaches; Performance tuning; Capacity planning.
Initially you should identify the probable performance and scalability based on the requirements. You should be asking about: numbers of users/components; component interactions; throughput and transaction rates; performance requirements.
Factor in batch requirements and performance characteristics of dependent (sub)systems. Note that additional layers, like security, add overheads to performance.
Logging and stateful EJB can degrade performance.
After the initial identification phase, the target should be for a model architecture that can be load-tested to feedback information.
Scalability hotspots are more likely to exist in the tiers that are shared across multiple client sessions.
Performance measurements should be from presentation start to presentation completion, i.e. user clicks button (start) and information is displayed (completion).
Use load-test suites and frameworks to perform repeatable load testing.

http://www.sys-con.com/java/article.cfm?id=671
J2EE Application server performance (Page last updated April 2001, Added 2001-04-20, Author Misha Davidson, Publisher Java Developers Journal). Tips:

Avoid using the SingleThreadModel interface for servlets: write thread-safe code instead.
ServletRequest.getRemoteHost() is very inefficient, and can take seconds to complete the reverse DNS lookup it performs.
OutputStream can be faster than PrintWriter. JSPs are only generally slower than servlets when returning binary data, since JSPs always use a PrintWriter, whereas servlets can take advantage of a faster OutputStream.
Excessive use of custom tags may create unnecessary processing overhead.
Using multiple levels of BodyTags combined with iteration will likely slow down the processing of the page significantly.
For read-only queries involving large amounts of data, avoid EJB objects and use JavaBeans as an intermediary to access manipulate and store the data for JSP access.

http://www-4.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Paper detailing the "Best Practices for Developing High Performance Web and Enterprise Applications" using IBM's WebSphere. All the tips are generally applicable to servlet/EJB development, as well as other types of server development. (Page last updated September 2000, Added 2001-01-19, Author Harvey W. Gunther, Publisher IBM). Tips:

Do not store large object graphs in javax.servlet.http.HttpSession. Servlets may need to serialize and deserialize HttpSession objects for persistent sessions, and making them large produces a large serialization overhead.
Use the tag "<%@ page session="false"%>" to avoid creating HttpSessions in JSPs.
Minimize synchronization in Servlets to avoid multiple execution threads becoming effectively single-threaded.
Do not use javax.servlet.SingleThreadModel.
Use the HttpServlet Init method to perform expensive operations that need only be done once.
Minimize use of System.out.println.
Access entity beans from session beans, not from client or servlet code.

http://www.sys-con.com/java/article.cfm?id=1171
J2EE Performance tuning (Page last updated October 2001, Added 2001-10-22, Author James McGovern, Publisher Java Developers Journal). Tips:

Call HttpSession.invalidate() to clean up a session when you no longer need to use it.
For Web pages that don't require session tracking, save resources by turning off automatic session creation using: <%@ page session="false"%>
Implement the HttpSessionBindingListener for all beans that are scoped as session interface and explicitly release resources implementing the method valueUnbound().
Timeout sessions more quickly by setting the timeout or using session.setMaxInactiveInterval().
Keep-Alive may be extra overhead for dynamic sites.
Use the include directive <%@ include file="copyleft.html" %> where possible, as this is a compile-time directive (include action <jsp:include page="copyleft.jsp" /> is a runtime directive).
Use cache tagging where possible.

http://win-www.uia.ac.be/~s985218/professional/thesis/archief/documenten/Marktoverzicht.doc
Overview of common application servers. (Announced at http://www.theserverside.com/home/thread.jsp?thread_id=9581). I've extracted the performance related features (Page last updated October 2001, Added 2001-10-22, Author Pieter Van Gorp, Publisher Van Gorp). Tips:

Optimized subsystems (RMI, JMS, JDBC drivers, JSP tags & cacheable page fragments).

http://intranetjournal.com/articles/200110/gb_10_24_01a.html
Website performance. (Page last updated October 2001, Added 2001-11-27, Author Gordon Benett, Publisher Intranet Journal). Tips:

Some e-commerce consultants cite an attention span on the order of eight seconds as the threshold for abandoning a slow retail site.
Where broadband connections are the norm, pages that don't appear instantly stand a good chance of never being seen: slow pages might as well be no pages.
Systems can only be designed to meet performance goals if those goals have been identified. Determine what range of response times will be acceptable.
Try to understand the performance impacts of your design decisions. However the performance of some design choices can be hard to predict and may remain unclear before testing.
Test the system under conditions that simulate real patterns of use.
Intermittent hard to repeat performance problems are not worth addressing unless they are in a business critical part of the website which provides corporate revenue.
Use a rapid, iterative development process in combination with frequent performance testing.
Try to plan up-front rather than have to rely on late-phase tuning.

http://www.fawcette.com/javapro/2002_01/magazine/columns/weblication/
Database performance (Page last updated December 2001, Added 2001-12-26, Author Peter Varhol, Publisher JavaPro). Tips:

Thoughtful page design makes for a better user experience by enabling the application to seem faster than it really is.

http://www.precisejava.com/javaperf/j2ee/EJB.htm
EJB performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

Use the HttpSession object rather than a Stateful session bean to maintain client state.

http://www.precisejava.com/javaperf/j2ee/Servlets.htm
Servlet performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

Use the servlet init() method to cache static data, and release them in the destroy() method.
Use StringBuffer rather than using + operator when you concatenate multiple strings.
Use the print() method rather than the println() method.
Use a ServletOutputStream rather than a PrintWriter to send binary data.
Initialize the PrintWriter with the optimal size for pages you write.
Flush the data in sections so that the user can see partial pages more quickly.
Minimize the synchronized block in the service method.
Implement the getLastModified() method to use the browser cache and the server cache.
Use the application server's caching facility.
Session mechanisms from fastest to slowest are: HttpSession, Hidden fields, Cookies, URL rewriting, the persistency mechanism.
Remove HttpSession objects explicitly in your program whenever you finish the session.
Set the session time-out value as low as possible.
Use transient variables to reduce serialization overheads.
Disable the servlet auto reloading feature.
Tune the thread pool size.

http://www.onjava.com/pub/a/onjava/2002/07/17/web.html
High load web servlets (Page last updated July 2002, Added 2002-07-24, Author Pier Fumagalli, Publisher OnJava). Tips:

Hand off requests for static resources directly to the web server by specifying the URL, not by redirecting from the servlet.
Use separate webservers to deliver static and dynamic content.
Cache as much as possible. Make sure you know exactly how much RAM you can spare for caches, and have the right tools for measuring memory.
Load balance the Java application using multiple JVMs.
Use ulimit to monitor the number of file descriptors available to the processes. Make sure this is high enough.
Logging is more important than the performance saved by not logging.
Monitor resources and prepare for spikes.

http://www.precisejava.com/javaperf/j2ee/JSP.htm
JSP performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

Use the jspInit() method to cache static data, and release them in the jspDestroy() method.
Use the jspInit() method to cache static data.
Use StringBuffer rather than using + operator when you concatenate multiple strings.
Use the print() method rather than the println() method.
Use a ServletOutputStream rather than a PrintWriter to send binary data.
Initialize the PrintWriter with the optimal size for pages you write.
Flush the data in sections so that the user can see partial pages more quickly.
Minimize the synchronized block in the service method.
Avoid creating a session object with the directive <%@ page session="false" %>
Increase the buffer size of System.out with the directive <%@ page buffer="12kb" %>
Use the include directive instead of the include action when you want to include another page.
Minimize the scope of the 'useBean' action.
Custom tags incur a performance overhead. Use as few as possible.
Use the application server's caching facility, and the session and application objects (using getAttribute()/setAttribute()). There are also third-party caching tags available.
Session mechanisms from fastest to slowest are: session, Hidden fields, Cookies, URL rewriting, the persistency mechanism.
Remove 'session' objects explicitly in your program whenever you finish the session.
Reduce the session time-out as low as possible.
Use 'transient' variables to reduce serialization overheads.
Disable the JSP auto reloading feature.
Tune the thread pool size.

http://www.onjava.com/pub/a/onjava/2002/07/10/jboss.html
Clustering with JBoss (Page last updated July 2002, Added 2002-07-24, Authors Bill Burke, Sacha Labourey, Publisher OnJava). Tips:

A hardware- or software-based HTTP load-balancer usually sits in front of the application servers within a cluster. The load balancer can decrypt HTTPS requests and distribute load.
HTTP session replication is expensive for a J2EE application server. If you can live with forcing a user to log in again after a server failure, then an HTTP load-balancer probably provides all of the fail-over and load-balancing functionality you need.
If you are storing things other than EJB Home references in your JNDI tree, then you may need clustered JNDI.

http://java.ittoolbox.com/pub/SC071902/httprevealer_servlets_itx.htm
Speeding web page downloads using compression (Page last updated July 2002, Added 2002-07-24, Author Steven Chau, Publication HttpRevealer.com, Publisher HttpRevealer.com). Tips:

Browsers sending "Accept-Encoding: gzip" will accept gziped compressed pages. Return the page compressed with "Content-Encoding: gzip" using GZIPOutputStream.
Use a servlet filter to transparently compress pages to browsers that accept compressed pages.

http://www.stqemagazine.com/featured.asp?id=10
Web application scalability. (Page last updated June 2000, Added 2001-05-21, Author Billie Shea, Publisher STQE Magazine). Tips:

Web application scalability is the ability to sustain the required number of simultaneous users and/or transactions, while maintaining adequate response times to end users.
The first solution built with new skills and new technologies will always have room for improvement.
Avoid deploying an application server that will cause embarrassment, or that could weaken customer confidence and business reputation [because of bad response times or lack of calability].
Consider application performance throughout each phase of development and into production.
Performance testing must be an integral part of designing, building, and maintaining Web applications.
There appears to be a strong correlation between the use of performance testing tools and the likelihood that a site would scale as required.
Automated performance tests must be planned for and iteratively implemented to identify and remove bottlenecks.
Validate the architecture: decide on the maximum scaling requirements and then performance test to validate the necessary performance is achievable. This testing should be done on the prototype, before the application is built.
Have a clear understanding of how easily your configurations of Web, application, and/or database servers can be expanded.
Factor in load-balancing software and/or hardware in order to efficiently route requests to the least busy resource.
Consider the effects security will have on performance: adding a security layer to transactions will impact response times. Dedicate specific server(s) to handle secure transactions.
Select performance benchmarks and use them to quantify the scalability and determine performance targets and future performance improvements or degradations. Include all user types such as "information-gathering" visitors or "transaction" visitors in your benchmarks.
Perform "Performance Regression Testing": continuously re-test and measure against the established benchmark tests to ensure that application performance hasn?t been degraded because of the changes you?ve made.
Performance testing must continue even after the application is deployed. For applications expected to perform 24/7 inconsequential issues like database logging can degrade performance. Continuous monitoring is key to spotting even the slightest abnormality: set performance capacity thresholds and monitor them.
When application transaction volumes reach 40% of maximum expected volumes, it is time to start executing plans to expand the system

http://www.stqemagazine.com/featured.asp?id=15
Web Load Test Planning (Page last updated April 2001, Added 2001-05-21, Author Alberto Savoia, Publisher STQE Magazine). Tips:

The only reliable way to determine a system?s scalability is to perform a load test in which the volume and characteristics of the anticipated traffic are simulated as realistically as possible.
It is hard to design and develop load tests that come close to matching real loads.
Characterize the anticipated load as objectively and systematically as possible: use existing log files where possible; characterize user sessions (pages viewed - number and types; duration of session; etc). Determine the range and distribution of variations in sessions. Don't use averages, use representative profiles.
Estimate target load and peak levels: estimate overall and peak loads for the server and expected growth rates.
Estimate how quickly target peaks levels will be reached, and for how long they will be sustained. The duration of the peak is important and the server must be designed to handle it.
The key elements of a load test design are: test objective (e.g. can the server handle N sessions/hr peak load level?); pass/fail criteria (e.g. pass if response times stay within define values); script description (e.g. user1: page1, page2, ...; user2: page1, page3, start transaction1, etc); scenario description (which scripts at which frequency, and how load increases).

http://www.theserverside.com/resources/articles/JSP-Performance/ProJsp.html
Performance chapter (chapter 20) from "Professional JSP 2nd Edition" (Page last updated August 2001, Added 2001-10-22, Author Simon Brown, Robert Burdick, Darko Cokor, Jayson Falkner, Ben Galbraith, RodJohnson, Larry Kim, Casey Kochmer, Thor Kristmundsson, Sing Li, Dan Malks, Mark Nelson, Grant Palmer, Bob Sullivan, Geoff Taylor, John Timney, Sameer Tyagi, Geert Van Damme, Steve Wilkinson, Publisher The Server Side). Tips:

The user's view of the response time for a page view in his browser depends on download speed and on the complexity of the page. e.g. the number of graphics. A poorly-designed highly graphical dynamic website could be seen as 'slow' even if the web downloads are individually quite fast.
No web application can handle an unlimited number of requests; the trick in optimization is to anticipate the likely user demand and ensure that the web site can gracefully scale up to the demand while maintaining acceptable levels of speed.
Profile the server to identify the bottlenecks. Note that profiling can be done by instrumenting the code with measurement calls if a profiler is unavailable.
One stress test methodology is: determine the maximum acceptable response time for getting a page; estimate the maximum number of simultaneous users; simulate user requests, gradually adding simulated users until the web application response delay becomes greater than the acceptable response time; optimize until you reach the desired number of users.
Pay special attention to refused connections during your stress test: these indicate the servlet is overwhelmed.
There is little performance penalty to using an MVC architecture.
Use resource pools for expensive resources (like database connections).
Static pages are much faster than dynamic pages, where the web server handles static pages separately.
Servlet filtering has a performance cost. Test to see if it is an acceptable cost.
Ensure that the webserver is configured to handle the expected number of user for example: enough ready sockets; enough disk space; enough CPU.
Use the fastest JVM you have access to.

http://theserverside.com/home/thread.jsp?thread_id=3276
Some performance tips (Page last updated January 2001, Added 2001-01-19, Author Shyam Lingegowda, Publisher The Server Side). Tips:

Factor out constant computations from loops. For Servlets, push one time computations into the init() method.

http://www.onjava.com/pub/a/onjava/2002/01/09/dataexp1.html
Expiring cached data (Page last updated January 2001, Added 2002-01-25, Author William Grosso, Publisher OnJava). Tips:

Servlet sessions expire after a settable timeout, but screens that automatically refresh can keep a session alive indefinitely, even when the screen is no longer in use.

http://www.aceshardware.com/read.jsp?id=45000251
Report of how Ace's Hardware made their SPECmine tool blazingly fast (Page last updated December 2001, Added 2002-02-22, Author Chris Rijk, Publisher Ace's Hardware). Tips:

Tranform your data to minimize the costs of searching it.
If your dataset is small enough, read it all into memory or use an in-memory database (keeping the primary copy on disk for recovery).
An in-memory datavase avoids the following overheads: no need to pass data in from a separate process; less memory allocation by avoiding all the data copies as it's passed between processes and layers; no need for data conversion; fine-tuned sorting and filtering possible; other optimizations become simpler.
Pre-calculation makes some results faster by making the database data more efficient to access (by ordering it in advance for example), or by setting up extra data in advance, generated from the main data, to make calculating the results for a query simpler.
Pre-determine possible data values in queries, and use boolean arrays to access the chosen values.
Pre-calculate all formatting that is invariant for generated HTML pages. Cache all reused HTML fragments.
Caching many strings may consume too much memory. IF memory is limited, it may be more effective to generate strings as needed.
Write out strings individually, rather than concatenating them and writing the result.
Extract common strings into an identical string object.
Compress generated html pages to send to the user, if their browser supports compressed html. This is a heavier load on the server, but produces a significantly faster transfer for limited bandwidth clients.
Some pages are temporarily static. Cache these pages, and only re-generate them when they change.
Caching can significantly improve the responsiveness of a website.

http://www-106.ibm.com/developerworks/webservices/library/ws-testsoap/
Scaling SOAP-based web services. (Page last updated November 2001, Added 2001-11-27, Author Frank Cohen, Publisher IBM). Tips:

Use simple SOAP data types (String, Int, Float, NegativeInteger).
Each new data type introduces a serializer to convert from the XML value into a Java value and back again, which may cause performance problems.
SOAP messages move much more data than the average HTTP GET or POST call, adversely impacting network performance.

http://www.sys-con.com/java/article.cfm?id=712
J2EE challenges (Page last updated June 2001, Added 2001-07-20, Author Chris Kampmeier, Publisher Java Developers Journal). Tips:

To ensure good performance use experienced J2EE builders and use proven design patterns.
Consider the impact of session size on performance.
Avoid the following common mistakes: Failure to close JDBC result sets, statements, and connections; Failure to remove unused stateful session beans; Failure to invalidate HttpSession.
Performance requirements include: the required response times for end users; the perceived steady state and peak user loads; the average and peak amount of data transferred per Web request; the expected growth in user load over the next 12 months.
Note that peak user loads are the number of concurrent sessions being managed by the application server, not the number of possible users using the system.
Applications that perform very little work can typically handle many users for a given amount of hardware, but can scale poorly as they spend a large percentage of time waiting for shared resources.

http://www.sys-con.com/java/article.cfm?id=673
J2EE Application servers (Page last updated April 2001, Added 2001-04-20, Authors Christopher G. Chelliah and Sudhakar Ramakrishnan, Publisher Java Developers Journal). Tips:

Application server caching should include web-page caches and data access caches. Other caches include caching servers which "guard" the application server, intercepting requests and either returning those that do not need to go to the server, or rejecting or delaying those that may overload the app server.

http://java.oreilly.com/news/jsptips_1100.html
Hans Bergsten's top ten JSP tips (Page last updated November 2000, Added 2001-01-19, Author Hans Bergsten, Publisher O'Reilly). Tips:

The include directive (<%@ include file="filename.inc" %>) is faster than the include action (<jsp:include page="pagename.jsp" flush="true"/>).
redirects are slower than forwards because the browser has to make a new request.
Database access is typically very expensive in terms of server resources. Use a connection pool to share database connections efficiently between all requests, but don't use the JDBC ResultSet object itself as the cache object.

http://www.onjava.com/pub/a/onjava/2001/03/01/pseudo_sessions.html
Pseudo Sessions for JSP, Servlets and HTTP (Page last updated March 2001, Added 2001-03-21, Author Budi Kurniawan, Publisher OnJava). Tips:

Use pseudo sessions rather than HttpSessions to improve web server scalability.
Pseudo sessions reside on file instead of in memory, thus both decreasing memory and allowing sessions to be distributed across multiple servers.
Pseudo sessions do not use cookies, instead they alter URLs to encode the session, and so reduce the generation of session objects by cookie-declining browsers.

http://www.javaworld.com/javaworld/jw-02-2001/jw-0223-extremescale.html
Clustering for J2EE and Java application servers. Looks at Bluestone Total-e-server, Sybase Enterprise Application Server, SilverStream Application Server, and WebLogic Application Server. (Page last updated February 2001, Added 2001-03-21, Author Abraham Kang, Publisher JavaWorld). Tips:

Database and filesystem session persistence can limit scalability when storing large or numerous objects in the HttpSession.
To scale the static portions of your Website, add Web servers; to scale the dynamic portions of your site, add application servers.

http://forums.itworld.com/webx?14@@.ee6bdcf/598!skip=542
Avoiding memory leaks in EJBs (Page last updated April 2001, Added 2001-05-21, Author Govind Seshadri, Publisher IT World). Tips:

Make sure that any beans which have session scope implement the HttpSessionBindingListener interface
Explicitly release the user's session by invoking invalidate() when they log out.
Try setting the session invalidation interval to a smaller value than the default 30 minutes.
Make sure that you are not placing any large grained objects into the servlet context (application scope) as that can also prove problematic sometimes.

http://www.java-pro.com/upload/free/features/Javapro/2001/07jul01/ah0107/ah0107-1.asp
Experiences building a servlet (Page last updated June 2001, Added 2001-06-18, Author Asif Habibullah, Jimmy Xu, Publisher Java Pro). Tips:

Keep the size of the client tier small so that downloads are fast.
Use the servlet init() and destroy() methods to start and stop limited and expensive resources, such as database connections.
Make the servlets thread-safe and use connection pooling.
Use PreparedStatements rather than plain Statement objects.
Use database stored procedures.

http://www.devx.com/upload/free/Features/Javapro/2002/02feb02/bk0202/bk0202-1.asp
Servlet 2.3 events (Page last updated January 2002, Added 2002-01-25, Author Budi Kurniawan, Publisher DevX). Tips:

The Servlet 2.3 specification adds application and session events. [Event driven applications can often be scaled more easily than process driven applications].

http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters.html
Servlet Filters (Page last updated June 2001, Added 2001-07-20, Author Jason Hunter, Publisher JavaWorld). Tips:

Servlet Filters provide a standardized technique for wrapping servlet calls.
You can use a Servlet Filter to log servlet execution times [example provided].
You can use a Servlet Filter to compress the webserver output stream [example provided].

http://www.onjava.com/pub/a/onjava/2001/09/18/jboss.html
Implementing clustering on a J2EE web server (JBoss+Jetty) (Page last updated September 2001, Added 2001-10-22, Author Bill Burke, Publisher OnJava). Tips:

Hardware load balancers are a simple and fast solution to distributing HTTP requests to clustered servers.

http://developer.java.sun.com/developer/qow/archive/153/index.jsp
Minimizing space taken by HTTP downloads (Page last updated October 2001, Added 2001-10-22, Authors Gary Adams and Eric Giguere, Publisher Sun). Tips:

Use HttpConnection.getLength() to determine the number of bytes needed to to hold the data from a download.
Use a ByteArrayOutputStream to accumulate results if the content length is indeterminate.
The best performance is obtained from a 1.1 compliant webserver using persistent connections.

http://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache.html
Faster JSP with caching (Page last updated May 2001, Added 2001-05-21, Author Serge Knystautas, Publisher JavaWorld). Tips:

The (open source) OSCache tag library provides fast in-memory caching.
Cache pages or page sections for a set length of time, rather than update the page (section) with each request.
Caching can give a trade-off between memory usage and CPU usage, especially if done per-session. This trade-off must be balanced correctly for optimal performance.

http://www.javareport.com/html/from_pages/article.asp?id=4702&mon=9&yr=2001
Architecting and Designing Scalable, Multitier Systems (Page last updated August 2001, Added 2001-10-22, Author Michael Minh Nguyen, Publisher Java Report). Tips:

Separate the UI controller logic from the servlet business logic, and let the controllers be mobile so they can execute on the client if possible.
Validate data as close to the data entry point as possible, preferably on the client. This reduces the network and server load. Business workflow rules should be on the server (or further back than the front-end).
You can use invisible applets in a browser to validate data on the client.

http://www.sys-con.com/java/article.cfm?id=1081
Optimizing dynamic web pages (Page last updated July 2001, Added 2001-07-20, Author Helen Thomas, Publisher Java Developers Journal). Tips:

Dynamic generation of web pages is more resource intensive than delivering static web pages, and can cause serious performance problems.
Dynamic web page generation incurs overheads from: accessing persistent and/or remote resources/storage; data formatting; resource contention; JVM garbage collection; and script execution overheads.
Dynamic content caching tries to mitigate Dynamic web page generation overheads by reusing content that has already been generated to service a request.
JSP cache tagging solutions allow page and fragment level JSP output to be automatically cached.
On highly personalized sites page-level caching results in low cache hit rates since each page instance is unique to a user.
Component-level caching applies more extensively when components are reused in many pages, but requires manual identification of bottleneck components.

http://www.sys-con.com/weblogic/article.cfm?id=102
Precompiling JSPs (Page last updated July 2002, Added 2002-07-24, Author Steve Mueller, Scot Weber, Publisher Weblogic Developers Journal). Tips:

Precompile your JSPs one way or another to avoid the first user having a slow experience.

http://www.theserverside.com/resources/article.jsp?l=Is-EJB-Appropriate
Deciding whether EJB is appropriate. (Page last updated September 2001, Added 2001-10-22, Author Ed Roman, Publisher The Server Side). Tips:

An HTTP layer is not always necessary. Connecting directly to EJBs is faster and provides automatic load balancing.

http://www.aikido.ozactivity.com.au/doc/en/administration/server_tune_procs.html
Tuning tips intended for Sun's "Web Server" product, but actually generally applicable. (Page last updated 1999, Added 2000-10-23, Author ? - a Sun document, Publisher Aikido). Tips:

Use more server threads if multiple connections have high latency.
Use keep-alive sockets for higher throughput.
Increase server listen queues for high load or high latency servers.
Avoid or reduce logging.
Buffer logging output: use less than one real output per log.
Avoid reverse DNS lookups.
Write time stamps rather than formatted date-times.
Separate paging and application files.
A high VM heap size may result in paging, but could avoid some garbage collections.
Occasional very long GCs makes the VM hang for that time, leading to variability in service quality.
Doing GC fairly often and avoiding paging is more efficient.
Security checks consume CPU resources. You will get better performance if you can turn security checking off.

http://m5.peakin.com/html/body_performance.html
Various tips. For web servers? (Page last updated 2000, Added 2000-10-23, Author ?, Publisher ?). Tips:

Compression uses significant system resources. Don't use it on a server unless necessary.

http://docs.iplanet.com/docs/manuals/fasttrak/41/servlets/1-using.htm#17322
iPlanet Web Server guide to servlets, with a section at the end on "Maximizing Servlet Performance". (Page last updated July 2000, Added 2001-02-21, Author ?, Publisher Sun). Tips:

Try to optimize the servlet loading mechanism, e.g. by listing the servlet first in loading configurations.

http://developer.java.sun.com/developer/community/chat/JavaLive/2001/jl1113.html
Sun community chat on iPlanet (Page last updated November 2001, Added 2001-12-26, Author Edward Ort, Publisher Sun). Tips:

Optimal result caching (caching pages which have been generated) needs tuning, especially the timeout setting. Make sure the timeout is not too short.

Last Updated: 2024-11-29
Copyright © 2000-2024 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/tips/j2ee_srvlt.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us