JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

In his article about the util.concurrent package, Brian Goetz points out that "Most of us would never think of writing our own XML parser, text indexing and search engine, regular expression compiler, ...". We use existing standard packages. The open source community does sometimes recreate standard tools for a very good reason: to make them open source. But it gets a bit ridiculous when we end up with four versions of slightly different open source tools. This seems to the situation with Java profilers. We now have at least four open source versions, (jcoverage, EJP, jProf, simpleprofiler) all seemingly in alpha release. They are of varying ages, going back to 1999. As each one successively became unsupported by its author, it seems like the next one started being developed by someone else. Why?

A note from this newsletter's sponsor

The quality of articles being written is still impressive this month. My own article on nulling and GC was well received; Brian Goetz's article on util.concurrent, the first of a series, is excellent as usual with Brian. If garbage collection (GC) is of interest to you, Nagarajayya and Mayer have updated their GC tuning article to cover 1.4.1. The article is well worth reading in detail: 1.4.1 includes five (yes 5!) garbage collection algorithms, and the article explains their aims and interactions.

I don't normally list research articles that don't have concrete performance tips. But I've made an exception for Vivek Haldar's research paper on verifying compile time assists for JITs (actually entitled "Verifying Data Flow Optimizations for Just-in-Time Compilation"). Since 1.1, compile time optimizations have been gradually reduced until the -O does nothing, mainly because the JIT knows more at runtime and can apply better optimizations then. I've been waiting for techniques to appear which will reverse this process of leaving everything to runtime, after all at compile time you have far more time to do optimizations. Now Haldar's paper shows how the compiler can add optimization hints while still satisfying the Java security model, which was probably the biggest sticking point.

Otherwise, we list a number of other articles covering EJBs, servlets, JDBC, XML parsing, web services, performance monitoring and analysis, J2ME design and portability, and more.

The roundup and Javva are also here, and our interview this month is with Ed lycklama of Sitraka (now part of Quest), who gives us his interesting view of Java performance. And we also have all the new performance tips extracted from our listed articles.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• Sun will tweak the class file format to improve efficiency.
• More proposed language changes. Typesafe enums should be fast, but the others look like being slow (or neutral).
• "Java startup time is too slow" pressure group.
• Low level Java vs C# benchmark (Java is much faster).
• Performant releases OptiBench 2.0 J2EE performance monitor
• A review of PerformaSure.
• Chat on High Performance GUIs with the JFC/Swing API scheduled for Jan 21. 11:00 A.M. PST/7:00 P.M. GMT.

A note from this newsletter's sponsor

Tools

• (Free) Simple heap profiler (open source).
• (Commercial) StreamStore pure Java efficient embeddable database engine.

Recent Articles

• Does nulling variables help garbage collection (Jack Shirazi/Kabutz)
• The util.concurrent package (Brian Goetz/IBM)
• Optimizing EJB validation code (Brett McLaughlin/IBM)
• Long-running tasks (Serguei Eremenko/Builder.com)
• CPU usage monitoring (Vladimir Roubtsov /JavaWorld)
• Application server performance (Rohit Valia and Marina Sum/Sun)
• J2ME portability (Jeremy Wakefield, Keith Braithwaite & Tony Robinson/JavaDevelopersJournal)
• J2ME design patterns (Ben Hui/JavaWorld)
• Tuning 1.4.1 heap and GC (Nagendra Nagarajayya and J. Steven Mayer/Sun)
• Java Performance for DB2 Applications (John Campbell/IBM)
• Caching web services (Brian D. Goodman/IBM)
• Statistical analysis to help identify performance bottlenecks (ProactiveNet/ebizQ)
• Compile time assists for JITs (Vivek Haldar/Sun)
• Building a lightweight XML parser (Guang Yang/DevX)
• Safe data writing with memory mapped files (Greg Travis/DevX)
• Comparing The Performance of J2EE Servers (Christopher L Merrill/Web Performance Inc)

Jack Shirazi

The Roundup

A fascinating question on garbage collection in a Weblogic server offered some insight to high performance JMS issues. The messages being fired into the JMS queue were not being collected quickly enough, so memory usage continured increasing until out-of-memory was reached. The questioner had changed his system to use (Weblogic) message paging, which limits the number of messages held in the in-memory JMS queue, queueing further pending messages on the disk. As long as the messages did not have to be processed at maximum speed, the case in this application, then this is an acceptable solution. However, the problem that remained was excessively long garbage collections. To solve this problem, the respondants mostly suggested contacting Weblogic support. But a couple suggested using -Xincgc, the incremental GC option, which breaks GC into smaller chunks to minimize GC pause times. We never found out if this worked.

Another thread posed the interesting problem of needing to access a collection of objects in two ways (in this case by rank order, and by ID). The question was, how should the the array be sorted, and would a linear search provide adequate performance. Suggestions included: using two structures to redundantly store the data, e.g. ArrayList for the sorted access and HashMap for ID access; using an ordered Map such as TreeMap or LinkedHashMap; or simply using one sorted list and using linear search for small collections.

And the last thread that I'll look at this week from JavaRanch posed a similar data structures question. In this case the developer was looking to see if certain fields were present in each of three files containing up to a million records. The only responder to this question, Jim Yingst, gave a thorough analysis of the problem, pointing out the memory problems of searching through that amount of data, suggesting sorting the files and comparing them a fragment at a time, possibly using an external index structure to maintain a sorted order if direct sorting of the files was not possible.

JavaGaming.org

In my first professional programming position I remember watching an external expert and internal expert jousting over some code that was being put together to demonstrate a product. It looked like watching a couple of wizards at work, concocting some esoteric spell. I had that impression once again when reading the JavaGaming discussion about the optimum tile size to use in Java. Here were the animation experts, deciding on how best to draw tiles. It seems that the BLT call is the expensive bit, not the size of the tiles; background buffers BLT'd to screen using offsets are the way to handle changes in perspective; VolatileImage is essential, though not yet fully effective on Linux and not fully supportive of transparent images; and 2D games should use the 3D API, which gives you all you need plus many extra options for free.

Still in with the wizards, this time we have a Sun engineer (another one, apart from the ubiquitous Kesselman) informing how to draw scaled images the fastest. It turns out you may need to enable some forms of hardware scaling, you need to specify -Dsun.java2d.ddscale=true. Using -Dsun.java2d.trace=log helps to see what 2D primitives are being used. But the real gold was that Image.getScaledInstance() has some major performance issues, and you should get an image with Component.createImage() or GraphicsConfiguraton.createCompatibleImage(), and use one of the Graphics.drawImage() calls (which scales on-the-fly) to render your source image to the new image.

Does explicitly setting variables to null help garbage collection? This discussion, with a very good example, showed that there were cases when this was true. In particular, an example was given where Eden was full and an object could theoretically have been reclaimed to make space for a new object, since the new object was being reassigned to the data member variable holding the theoretically reclaimable object. But the reclaim couldn't happen because the data member variable still referenced the reclaimable object, preventing it from GC'd. Consequently, the object was promoted to old generation space, and later required a full mark-sweep GC to reclaim it. The same example with the data member first explicitly nulled was also tested, and showed a huge improvement in speed. The whole discussion is further summarized and extended in this article.

The Server Side

A question that comes up time and again is CMP vs. BMP performance. This time round, the question lead to the most inetersting discussion I've seen. The question, summarized elegantly by the originator:

Clearly BMP means I need to write the persistence layer, but I am confident the system will perform because I write the carefully crafted joining SQL for reading. CMP will reduce our codebase and sounds like Utopia... Can CMP really perform, or are we better staying with BMP supported by various data access patterns?

• no statefull session beans
• pool your session beans
• do not allow lazy reads
• consider using stored procedures to solve extreme cases
• Be nice to your container: free your entity and session beans, mybean = null;
• If your DB driver does not optimize the SQL talk, consider changing it for another one

Another poster asked whether JRockit was any good since the idea of a dedicated server-side JVM made sense to him. The only reply suggested that JRockit performed similarly to other JVMs, though the performance was highly dependent on the application. My advice is to try every JVM you have access to with your application. I can guarantee that they will all produce different performance, and that one will be the overall fastest for your application.

The final thread I'll look at asked about the performance gains from clustering the servlet layer and the EJB layer separately. Did the gains from the separately scaled layers outweigh the losses from making all servlet/EJB class remote? Well, there was no answer from anyone who had actually done this, but the sole reply from Joe Hoffman did give a good rationalization to suggest that: "the larger the system is, the more sense it makes to specialize certain VM's to certain tasks. In small systems, this specialization probably doesn't make much sense and is not worth the complexity."

Javva The Hutt

During the dot bomb, I was the CTO of a fantastically successful startup. Well, okay, the company was a couple of guys I knew, no employees, and we almost got first round funding before the stock market meltdown. I didn't even give up my day job. But the thrill was unbelievable, and can you blame me for trying to get on the bandwagon? One day we were talking to VC guys about $10 million, looking forward to becoming overnight paper millionaires and adding our great products to the world economy; the next day they didn't remember ever meeting us and we were back to being joe nobodies. I don't like real roller coaster rides, but looking back on it, this virtual one was kinda fun.

Over on DevX, they have The diary of a startup. If you are at all interested in the startup business process, this is one way to live someone else's ride.

Diary of a Hutt

November 13. Damn, what were those guys thinking! Bloody Pet Store might be a bloody toy application but they're making bloody waves! Of course I'm the performance expert here, so I have to explain up the chain why Java is faster and no we don't need to start evaluating DOTNOT to see if we should be implementing this and no there's no need to re-evaluate our forward plans on that and ... Scrrrrreeeeeeeaaaaaammmmmm!!!! What the hell did they use to profile the application? new Date()? Why do I have the strong feeling that I've just been royally screwed when a company that I didn't commission has tested a non-benchmark application against another system that I don't care about using incompetent procedures and inexperienced engineers to provide a pointless comparison. And why am I having to spend lots of time explaining all this here!!!

November 20. No freebies yet. What kind of salesman doesn't give away freebies worth a tiny fraction of their product to close the deal? Either these guys are better than I thought, or our industry is doing much worse than I thought. Can anyone reading this tell me if companies have ruled out giving away freebies now?

November 28. Jack's comments on the Pet Store fiasco (November newsletter) were spot on. Someone at Microsoft probably got a big bonus for this PR job. Oracle's implementation 20 times faster than Microsoft's! How come no one else is publicising that? Well at least I can point my bigwigs to that.

BCNU

Javva The Hutt.

The Interview: Ed Lycklama, co-founder of Sitraka

This month we got to interview Ed Lycklama, previously the chief technology officer and co-founder of Sitraka. Ed is recognized as an expert in Java technology-based application performance issues, and JavaPerformanceTuning.com asked him some questions on Java performance.

Q. Can you tell us a bit about yourself and what you do?

Sure. I?m the Chief Architect, J2EE Solutions for Sitraka, which has recently been acquired by Quest Software. My responsibilities include providing technical direction for Quest?s J2EE performance management strategy, and interfacing with product groups to define J2EE product integration strategies.

Q. What do you consider to be the biggest Java performance issue currently?

Java applications run in a variety of environments (everywhere from hand-helds to huge mainframes) and the performance challenges are very different for each. With server-side applications written for J2EE application servers, the performance challenges typically revolve around excessive or inefficient accesses to backend systems such as databases, naming directories, and mainframe systems.

Q. Do you know of any requirements that potentially affect performance significantly enough that you find yourself altering designs to handle them?

Many enterprise-class applications include a requirement to support a large number of concurrent users. I have yet to see the implications of that requirement spelled out in detail. In general, a large number of concurrent users increase the contention on critical resources. Any exclusive access to those shared resources should be streamlined to avoid unnecessary queuing. Finding ways to avoid accessing that resource by employing a data caching strategy will also reduce overall contention.

Q. Can you tell us a little about Sitraka's products?

With several award-winning products that help companies to pinpoint and eliminate performance hazards in mission-critical J2EE applications Sitraka, recently acquired by Quest Software, has been a long standing leader in the Java market. Products include PerformaSure, a transaction-centric J2EE diagnosis solution, JProbe performance tuning tools, JClass Java components and DeployDirector, a Java application deployment solution.

Q. How has the acquisition affected things?

The combination of Quest and Sitraka enables us to offer customers additional value in the form of a leading application management product set that spans the application life cycle, all from a single-source supplier with a global infrastructure and public company accountability.

Customers can rest assured of business as usual at Sitraka.

Q. What are the most common performance related mistakes that you have seen projects make when developing Java applications?

Well, as stated in a previous answer, one of the biggest mistakes is failing to take scalability requirements into account when designing the overall application. Failure to do so can result in last-minute fire-fighting disasters, threatened deployment dates, alienated customers and exploded budgets.

Q. Have you found any Java performance benchmarks useful?

I?m not a big believer in performance benchmarks, especially in areas as complicated as J2EE applications that span diverse computing platforms and interact with legacy applications.

Q. Do you know of any performance related tools that you would like to share with our readers?

I?m glad you asked that! Let me tell you a little more about our two product families focused on J2EE performance.

PerformaSure is a transaction-centric diagnosis tool that helps companies to measure, analyze and maximize performance of multi-tiered J2EE applications during load testing and before costly problems occur in production.

JProbe is a comprehensive, award-winning toolkit for diagnosing code errors and inefficiencies. With performance profiling, memory debugging, thread analysis and code coverage tools, JProbe paints graphical pictures of everything from memory usage to calling relationships, helping developers understand precisely what is causing problems in a Java application - right down to the offending line of source code.

Together, PerformaSure and JProbe provide a highly targeted solution that enables rapid identification and repair of business-threatening performance problems.

Q. Do you have any particular performance tips you would like to tell our readers about?

How about some advice: every application is different, and will have its own performance and scalability issues. The only way to determine what those issues are, and how you can get the most out of your application (whether that means supporting more users with less hardware, or delivery responses more quickly), is to measure your application with realistic scenarios and use a highly targeted performance assurance solution to identify and eliminate costly performance problems. 0bviously I?d like to recommend PerformaSure and JProbe - but in any case - use something: remember, if you can?t measure it, you can?t fix it.

(End of interview).

Tips

http://www.javaspecialists.co.za/archive/Issue060.html
Does nulling variables help garbage collection (Page last updated November 2002, Added 2002-12-27, Author Jack Shirazi, Publisher Kabutz). Tips:

• In some rare situations, explicitly nulling a variable reference can allow the garbage collector to reclaim an object in the young generation, avoiding promoting that object and having to reclaim it more slowly in the old generation.
• Object cycling (creation then deletion) is an order of magnitude faster in the young generation than the old generation.
• Objects that are too large to fit into the young generation must be created directly in the old generation.
• Correctly scoping objects avoids having to rely on nulling variables to dereference objects.
• Tuning the heap is worthwhile and can avoid you having to make code changes.

http://www-106.ibm.com/developerworks/java/library/j-jtp1126.html
The util.concurrent package (Page last updated November 2002, Added 2002-12-27, Author Brian Goetz, Publisher IBM). Tips:

• wait(), notify(), and synchronized are tricky to use correctly and there are many performance, deadlock, fairness, resource management, and thread-safety hazards to avoid.
• Doug Lea's util.concurrent is a well tried free package of concurrency utilities that will form the basis of the java.util.concurrent package in JDK 1.5. util.concurrent supports timing out locks; interrupting lock acquisition attempts; creating shared locks; supporting multi-mode locking, such as concurrent-read with exclusive-write; acquire a lock in one method and release it in another; etc.
• A real-world task scheduler should deal with threads that die, kill excess pool threads so they don't consume resources unnecessarily, manage the pool size dynamically based on load, and bound the number of tasks queued. util.concurrent includes efficient thread pool management.
• util.concurrent includes efficient asynchronous process scheduling.

http://www-106.ibm.com/developerworks/java/library/j-ejb1217.html
Optimizing EJB validation code (Page last updated December 2002, Added 2002-12-27, Author Brett McLaughlin, Publisher IBM). Tips:

• Place all your data validation code (ensuring data is the correct type/format/range) in the business delegate methods (which execute on the client). Keep your data validation logic as close to the client as possible to minimize unnecessary requests to the server.
• Business-specific validation (testing against business rules, e.g. a specific book exists) should be in the EJB layer optimized to use local calls.

http://builder.com.com/article.jhtml?id=u00220021119sge01.htm&fromtm=e027
Long-running tasks (Page last updated November 2002, Added 2002-12-27, Author Serguei Eremenko, Publisher Builder.com). Tips:

• [Article describes a class designed for efficiently managing long running tasks].

http://www.javaworld.com/javaworld/javaqa/2002-11/01-qa-1108-cpu.html
CPU usage monitoring (Page last updated November 2002, Added 2002-12-27, Author Vladimir Roubtsov , Publisher JavaWorld). Tips:

• Programmatically querying for CPU usage is not possible using pure Java, you need to use a JNI call.
• [Article describes implementing a JNI call to getProcessCPUTime() to get CPU usage of the system].

http://java.sun.com/features/2002/11/appserver_influences.html
Application server performance (Page last updated November 2002, Added 2002-12-27, Author Rohit Valia and Marina Sum, Publisher Sun). Tips:

• HTTPS is characterized by light inbound/heavy outbound traffic. SSL requires heavy CPU usage.
• Each type of application has its own performance profile. Benchmark your application using measurment toolkits.

http://www.sys-con.com/java/article.cfm?id=1783
J2ME portability (Page last updated December 2002, Added 2002-12-27, Author Jeremy Wakefield, Keith Braithwaite & Tony Robinson, Publisher JavaDevelopersJournal). Tips:

• It's possible for a MIDP implementation to pass the TCK tests and not perform well at all.
• MIDlets allocate resources in startApp() and release them in destroyApp(). MIDlets PAUSED by the device's operating system must release expensive or volatile resources. Some platforms call destroyApp() when the MIDlet is PAUSED, and create a new instance when it returns to the foreground. A MIDlet should expect the possibility of being DESTROYED when PAUSED, and manage resources accordingly.

http://www.javaworld.com/javaworld/jw-12-2002/jw-1213-j2medesign.html
J2ME design patterns (Page last updated December 2002, Added 2002-12-27, Author Ben Hui, Publisher JavaWorld). Tips:

• [Article presents several design patterns suitable for J2ME applications].
• It takes a lot of memory and processing power to show 1,000 strings on a mobile phone. Use the Pagination pattern to divide data into pages.

http://wireless.java.sun.com/midp/articles/garbagecollection2/
Tuning 1.4.1 heap and GC (Page last updated November 2002, Added 2002-12-27, Author Nagendra Nagarajayya and J. Steven Mayer, Publisher Sun). Tips:

• 1.4.1 has three young generation collectors (copying collector; parallel copying collector; parallel scavenge collector) and two old generation collectors (mark-compact collector and concurrent collector).
• The parallel copying collector uses multiple threads (one per CPU by default) to garbage collect the young generation, thus should be faster than the default single-threaded copying collector on multiple-CPU machines. Enabled by using the -XX:+UseParNewGC option (though on a single CPU machine the default copy collector is still used since it is more efficient in that case). The -XX:ParallelGCThreads=<num threads> option can be used to specify a different number of threads from the default (one per CPU), and can force the use of this collector on a single CPU machine.
• The concurrent collector minimizes the stop-the-world portions of the old generation garbage collection, thus minimizing application pause times. Most of the concurrent collector GC occurs concurrently with the application. Enabled by using the -XX:+UseConcMarkSweepGC option. The concurrent collector background thread starts running when the percentage of allocated space in the old generation goes above the -XX:CMSInitiatingOccupancyFraction=<percent>, default value is 68%. If "the rate of creation" of objects is too high, and the concurrent collector is not able to keep up with the concurrent collection, it falls back to the traditional mark-sweep collector.
• The parallel scavenge collector is similar to the parallel copying collector but is optimized for large systems: mutliple CPUs and heap sizes above 10 gigabytes. Enabled by using the -XX:UseParallelGC option, which forces old generation GC to use the original mark-compact old generation collector. With large heaps, the -XX:TargetSurvivorRatio should pronbably be increased beyond the default of 50. The -XX:ParallelGCThreads=<num threads> option can be used to specify a different number of threads from the default (one per CPU), and can force the use of this collector on a single CPU machine. Adaptive sizing can be turned on with the -XX:+UseAdaptiveSizePolicy option.
• The mark compact (original) old generation garbage collector is very efficient where pause time is not a big criterion.
• 1.4.1 heap consist of: permanent generation, used to store class objects and related meta data (sized using -XX:PermSize and -XX:MaxPermSize, use -Xnoclassgc to prevent GC here); old generation used to hold old objects promoted from the younger generation (sized using -Xms and -Xmx which specifies the total sizes of young and old generation combined); and young generation which is further divided into an Eden, and two semi-spaces (sized using -XX:NewSize, -XX:MaxNewSize, -XX:SurvivorRatio such that EdenSize = NewSize - ((NewSize / ( SurvivorRatio + 2)) * 2) and SemispaceSize = (NewSize - EdenSize) / 2).
• The -XX:MaxTenuringThreshold=<N> option specifies how many collections an object can remain in the young generation, after which it is promoted to the old generation. The promoteall option (last available in 1.2.2) which immediately promoted any object that survived a young generation to old generation space, can be simulated using -XX:MaxTenuringThreshold=0 (in which case there is no need for any semispace, so they should be sized extremely small in conjunction, e.g. -XX:SurvivorRatio=20000).
• [Article gives an example of using Amdahls law to predict the parallelism efficiency of an application from its GC costs].
• Options that generate GC logging are -verbose:gc, -XX:+PrintGCDetails, -XX:+PrintGCTimeStamps, -XX:+PrintHeapAtGC. Note that -Xloggc does not log data from the -XX switches. [Article describes the information available when using these options].
• [Article provides an analysis script to analyze the GC logging output available from 1.4.1 GC logging options].
• If the application has few intermediate objects (objects surviving one or more young generations GCs), using the promoteall modifier decreases the amount of time that the application spends copying in young GC. But the collection cost is moved to old generation GC, which may be worse.
• Copy collection is directly proportional to the size of the live objects.
• Dereference objects (perhaps by nulling the variable pointing to them) as soon as they are no longer needed.
• Avoid creating unnecessary objects.
• Pooling objects can easily cost more to use than the time saved in GC. Objects are suitable for pooling when they: take a long time to create or use up a lot of memory (threads, db connections); are static objects, especially when they have no state.
• Temporary objects referenced from objects in the old generation (e.g. long-lived objects) have a higher scanning cost (young generation GC phase).
• Flattened objects are cheaper to garbage collect than the equivalent data in nested objects.
• The -XX:PretenureSizeThreshold=<byte size> (default 0) specifies the size of objects to create directly in the old generation. This option can easily degrade performance.
• NIO direct buffers are stored outside the heap, so avoid GC, and can be used to store long life objects like lookup tables, caches, etc. [Except presumably there is some GC when the buffer is released].
• Reference objects are expensive for the garbage collectors.
• Finalizers are very expensive for the garbage collectors.
• Finding the optimal size for the young generation is pretty easy. The rule of thumb is to make it about as large as possible, given acceptable collection (pause) times. There is a certain amount of fixed overhead with each collection, so their frequency should be minimized. If pauses are not an issue, young generation space should be made as large as possible.
• Old generation heap size needs to be balanced to minimize overall GC times. Too small a size leads to an increased rate of GC, to large a size leads to long GC times as the old generation GC time is proportional to the size of the heap.
• Old generation is not compacted by default, leading to a fragmented heap. The -XX:+UseCMSCompactAtFullCollection option can be used to enable compaction of the old generation heap at the cost of performance.
• Heaps large than physical memory incur operating system paging overheads which significantly degrades performance.
• [Article inludes Solaris specific tuning options, sections 16.2.6.1 and 18].

http://www7b.software.ibm.com/dmdd/library/techarticle/0202campbell/0202campbell.html
Java Performance for DB2 Applications (Page last updated November 2002, Added 2002-12-27, Author John Campbell, Publisher IBM). Tips:

• SQLJ can be faster than JDBC because some of the JDBC runtime overheads can be shifted to compilation time.
• Ensure the SQLJ serialized profile is customized correctly, and request online checking.
• Use the same ConnectionContext for corresponding SQLJ statements.
• Close resources (Resultsets, Statements, ...) when finished with
• Disable autocommit.
• SELECT and UPDATE only those columns you need.
• Tune the JVM heap.
• Use the latest JVM and JDBC driver.
• Turn on DB2 dynamic SQL statement caching with CACHEDYN=YES in your subsystem parameters (DSNZPARM).

http://www-106.ibm.com/developerworks/webservices/library/ws-cach1/
Caching web services (Page last updated December 2002, Added 2002-12-27, Author Brian D. Goodman, Publisher IBM). Tips:

• Web service performance depends on: Network transaction time; The time it takes to handle the message (XML parsing/generation, etc); The time the service itself takes to execute.
• Cache where possible [Article describes a few caching scenarios].

http://www.messageq.com/systems_management/proactivenet_1a.html
Statistical analysis to help identify performance bottlenecks (Page last updated November 2002, Added 2002-12-27, Author ProactiveNet, Publisher ebizQ). Tips:

• A user?s perception of a quality application experience is predominantly determined by the application?s response time and availability.
• Use statistical quality control to manage the huge volume of performance data: periodic statistical sampling, creation of "normal" control charts and focusing additional analysis on "abnormal" data points. Accurate baselining is critical.
• A series of analyses helps identify the causes of performance problems: 1 detect abnormal performance (outside expected ranges); 2 correlate abnormalities compared to baseline measurements for all other variables at about the same time as the alerted performance abnormality; 3 eliminate detected abnormalities that are unlikely causes; 4 score the remaining abnormalities according to degree of abnormailty and likely causation.

http://research.sun.com/techrep/2002/abstract-118.html
Compile time assists for JITs (Page last updated October 2002, Added 2002-12-27, Author Vivek Haldar, Publisher Sun). Tips:

• [Article describes how the compiler can add optimization hints while still satisfying the Java security model].

http://www.devx.com/xml/Article/10114
Building a lightweight XML parser (Page last updated November 2002, Added 2002-12-27, Author Guang Yang, Publisher DevX). Tips:

• A full-featured XML parser can be too resource intensive for your particular application. The SimpleDOMParser (described here) is a highly simplified, under 4 KB and fewer than 400 lines of source.
• SAX parsing provides better performance than DOM as SAX process one tag at a time, while DOM maintains global state. However SimpleDOMParser provides a simplified DOM which is not resource intensive.

http://www.devx.com/DevX/Article/10027
Safe data writing with memory mapped files (Page last updated November 2002, Added 2002-12-27, Author Greg Travis, Publisher DevX). Tips:

• Efficiently updating file based data caches changes in memory and writes it periodically to disk (called checkpointing).
• Using memory mapped files can be efficient because the underlying operating system manages disk pages on demand, only loading the data that is actually accessed.
• Any change to a memory mapped file immediately changes the file, so care must be taken to avoid corrupt states. The article describes a class which maintains changes in memory and duplicated in a disk-based "change log", efficiently applying changes atomically to avoid corrupt states. In case of a crash, the "change log" allows recovery to the last non-corrupt state.
• Writes to disk are not necessarily immediately flushed to disk, for efficiency reasons. You can force data to disk using MappedByteBuffer.force(), but this can slow down processing.

http://webperformanceinc.com/library/ServletReport/
Comparing The Performance of J2EE Servers (Page last updated November 2002, Added 2002-12-27, Author Christopher L Merrill, Publisher Web Performance Inc). Tips:

• [Report comparing the performance of servlet servers. Describes how to build a load test].

Jack Shirazi