The following pages have their detailed tips extracted below

• Overview of common application servers
• Scalable recoverable applications
• EJB performance tips
• High load web servlets
• JMS performance tips
• Clustering with JBoss
• Speeding web page downloads using compression
• Benchmarking JMS
• JMS vs RMI
• Multicasting efficiency
• JMS & CORBA
• JMS redelivery

The following detailed tips have been extracted from the raw tips page

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://www.theserverside.com/resources/article.jsp?l=Building-Sclable-Recoverable-Applications
Scalable recoverable applications (Page last updated May 2002, Added 2002-07-24, Author Billy Newport, Publisher The Server Side). Tips:

• A load balancing message queue may be needed for a high rate of messages (>500/sec).

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:

• Tune the Message driven beans pool size to optimize the concurrent processing of messages.

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/JMS.htm
JMS performance tips (Page last updated November 2001, Added 2001-12-26, Authors Ravi Kalidindi and Rohini Datla, Publisher PreciseJava). Tips:

• Start the consumer before you start the producer so that the initial messages do not need to queue.
• Use a ConnectionConsumer to process messages concurrently with a ServerSessionPool.
• Close resources (e.g. connections, session objects, producers, consumers) when finished with them.
• DUPS_OK_ACKNOWLEDGE and AUTO_ACKNOWLEDGE perform better than CLIENT_ACKNOWLEDGE.
• Use separate transactional sessions and non-transactional sessions for transactional and non-transactional messages.
• Tune the Destination parameters: a smaller capacity increases message throughput; a higher redelivery delay and lower redelivery limit reduces the overhead.
• Choose non-durable (NON_PERSISTENT) messages wherever appropriate to avoid the persistency overhead.
• Set the TimeToLive value as low as feasible (default is for messages to never expire).
• Receive messages asynchronously with a MessageListener implementation.
• Choose the message type that minimizes memory overheads.
• Use 'transient' variables to reduce serialization overheads.

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.sys-con.com/java/article.cfm?id=639
Benchmarking JMS (Page last updated March 2001, Added 2001-03-21, Author Dave Chappell, Bill Wood, Publisher Java Developers Journal). Tips:

• Scaling middleware exposes a number of issues such as threading contention, network bottlenecks, message persistence issues, memory leaks, and overuse of object allocations.
• [Article dicusses questions to ask when setting up benchmarks for messaging middleware].
• Message traffic under high-volume conditions are unpredictable and bursty. Messages can be produced far faster than they can be consumed, causing congestion. This condition requires the message sends to be throttled with flow control (could be an exception, or an automatic resend).
• When testing performance, run overnight and over weekends to generate longer term trends. Some concerns are: testing without a real network connection can give false measures; low user simulation can be markedly different from high user simulations; network throughput may be large than the deployed environment; nonpersistent message performance is dependent on processor and memory; disk speed is crucial for persistent messages.
• [Article provides a benchmark harness for testing JMS].

http://www.devx.com/premier/mgznarch/Javapro/2002/03mar02/kj0302/kj0302-1.asp
JMS vs RMI (Page last updated February 2002, Added 2002-02-22, Author Kevin Jones, Publisher DevX). Tips:

• RMI calls marshall and demarshall parameters, adding major overhead.
• Every network communication has several overheads: the distance between the sender and the receiver adds a minimum latency (limited by the speed the signal can travel along the wire, about two-thirds of the speed of light: London to New York would take about 3 milliseconds); each network router and switch adds time to respond to data, on the order of 0.1 milliseconds per device per packet.
• Part of most network communications consists of small control packets, adding significant overhead.
• One RMI call does not generally cause a noticeable delay, but even tens of RMI calls can be noticeable to the users.
• Beans written with many getXXX() and setXXX() methods can incur an RMI round trip for every data attribute.
• Messaging is naturally asynchronous, and allows an application to decouple network communications from ongoing processing, potentially avoiding threads from being blocked on communications.

http://www.messageq.com/communications_middleware/timberlake_1.html
Multicasting efficiency (Page last updated January 2002, Added 2002-02-22, Author Paul Timberlake, Publisher Message MQ). Tips:

• When dealing with large numbers of active listeners, multicast publish/subscribe is more efficient than broadcast or multiple individual connections (unicast).
• When dealing with large numbers of listeners with only a few active, or if dealing with only a few listeners, multicasting is inefficient. This scenario is common in enterprise application integration (EAI) systems. Inactive listeners require all missed messages to be resent to them in order when the listener becomes active.
• A unicast-based message transport, such as message queuing organized into a hub-and-spoke model, is more efficient than multicast for most application integration (EAI) scenarios.

http://www.onjava.com/pub/a/onjava/2001/12/12/jms_not.html
JMS & CORBA (Page last updated December 2001, Added 2001-12-26, Author Steve Trythall, Publisher OnJava). Tips:

• Asynchronous messaging is a proven communication model for developing large-scale, distributed enterprise integration solutions. Messaging provides more scalability because senders and receivers of messages are decoupled and are no longer required to execute in lockstep.

http://www.javaworld.com/javaworld/jw-03-2002/jw-0315-jms.html
JMS redelivery (Page last updated March 2002, Added 2002-03-25, Author Prakash Malani, Publisher JavaWorld). Tips:

• Both auto mode (Session.AUTO_ACKNOWLEDGE) and duplicate delivery mode (Session.DUPS_OK_ACKNOWLEDGE) guarantee delivery of messages, but duplicate okay mode can have a higher throughput, at the cost of the occasionally duplicated message.
• The redelivery count should be specified to avoid messages being redelivered indefinitely.