I was happy to see the Jakarta tools doing a good job of supporting most of these processes.
o Java's character to byte conversion is SLOW (by a factor of 10x -- Ed Korthof and Jon Stevens ran some tests to prove this for the MySQL MM JDBC driver, and we've seen this at CollabNet when writing large amount of data to a JServ socket). Avoid it when possible using caching of the character data converted to a byte[]. o Cache page fragments whenever possible. Velocity does a great job of this. o WebDAV rocks -- Remy and Juergen said so (and they mentioned Subversion briefly). ;-) The DASL specification (its searching interface), is nearing finalization. There is a CMS JSR in the pipes which will use Jakarta Slide as Sun's WebDAV reference implementation. o Always use pools for expensive resources like sockets and database connections (duh). Avoid servlet containers' single thread model to conserve memory through container-managed servlet caching (duh). o Address application/database clusters via a virtual name. o WebLogic/WebSphere use one or more "manager" app servers to register worker instances within a cluster. Bestowing "manager" status upon a worker instance seems like a good approach for cluster management. o Thread stack top analysis is very useful for identifying bottlenecks in multi-tier systems, often pointing out hot spots which static code analysis would miss entirely. It's performed by taking the top frame from each thread's stack, then counting the number of threads calling the same method and ranking them in descending order. You'll need to siphon out some types of high counts -- for instance, ignore things like sockets blocking on wait() -- that's just what threads do when they're not active. IBM has a tool called Thread Analyzer to help make sense of thread stack dumps (which hard hard to read without some sort of reporting tool). A SIGQUIT on Unix or a Control-C of a foreground process on Windows will produce a thread stack dump. o EJBs and other types of remote objects should always be coarse-grained. Avoiding pulling them from a remote source using caching or the EJB "by reference" model is a useful optimization. Message driven beans (MDBs) provide perceived speed (from a user's perspective). This is not limited to EJB/JMS -- CollabNet uses this scheme with a Torque/Spread <http://spread.org/> combination. o Pools of resource like threads, sockets, database connections, etc. are best optimized by closing approximating the average number of concurrent consumers (or max number, if you can afford the resources). o When running benchmarks (or "workloads"), always survey the system from a high level before moving in to test individual components. Test every component individually. o Adjusting JVM parameters for you environment can provide up to a 20% performance boost (with no code changes). Selecting GC type (i.e. aggressive, incremental, etc.) best suited for your environment is very important. A parallel/concurrent hybrid was the recommended method (but I don't think is yet available from anyone), and nurseries were also mentioned in a good light. Concurrent garbage collection runs in the VM at the same time as your Java program (not stoppage!), while parallel utilizes all available processors on the host. I heard a lot of buzz about a server-side JVM named JRockit <http://www.jrockit.com/about/features.html> from Appeal, which was recently acquired by BEA. It has 4 type of garbage collection <http://www.jrockit.com/about/gc.html>, including parallel and concurrent varieties, and the now-a-days garden variety compacting collector (not recommended for servers with many long-lived objects). JRockit also supports thread-local heaps, which I assume is similar to the Sun JVM's thread-local eden. Rumor has it that WebLogic may make JRockit freely available, but I'll believe it when I see it. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
