Back to newsletter 041 contents

http://otn.oracle.com/tech/java/architect/mwa_week8.html
Really Large Databases (Page last updated March 2004, Added 2004-04-29, Author Daniel Liu, Publisher Oracle). Tips:

• Create an architecture capable of scaling horizontally (across more and more machines).
• Machine and disk efficiency is important - use 64-bit CPUs and dedicated network disk management system.
• Eliminate data that is not necessary, such as historical data that is rarely referenced and could be archived.
• Stripe data randomly across the disks; spread it out evenly, trying to cross as many disks as possible and create a true randomness.
• Put data-intensive logic into the database tier instead of the middle tier.
• Monitor the database with snapshot and usage monitoring scripts (user and transaction concurrency). Active users, not just logged on users, is important.
• One pooled connection might produce the workload equivalent of ten or twenty dedicated connections.
• Tweak the following parameters for optimal performance of a large database: DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE, DB_BLOCK_SIZE, SHARED_POOL_SIZE, SHARED_POOL_RESERVED_SIZE, and CURSOR_SHARING.
• Limit the size of the share pool.

http://www.ddj.com/documents/s=9089/ddj0404f/0404f.htm
Genetic Algorithms & Optimal Solutions (Page last updated April 2004, Added 2004-04-29, Author Michael Larson, Publisher Dr. Dobb's Journal). Tips:

• [Article discusses applying a genetic algorithm to determine the optimal solution to a searching problem].

http://www.devx.com/wireless/Article/20292
9 Common Flaws of Unportable Mobile Java Apps (Page last updated March 2004 , Added 2004-04-29, Author Simon Keogh, Publisher devX). Tips:

• The size of the byte array used to store the sound element must be dynamic or provisioned to have expansion room. The file size may grow significantly when converting to less efficient sound file formats.
• Make provision for incoming calls or messages. The application should "pause" and "resume" appropriately. Handle both pauseApp/startApp and hideNotify/showNotify so that no matter which is called (or if both are called), the application can pause and resume properly.
• Construct UI elements with text with at least 30 percent expansion room for less compact languages (like German).
• Compose string resources in complete sentences or phrases. Concatenated strings should rarely be used.
• Text in help screens, about screens, or any other screens that are text intensive should be able to handle word wrapping.
• Avoid using images as text. If text is used in images then translated versions of the images should be provided.
• Keep the application size below 64KB. If you absolutely need a larger size for a complex application, then consider making a light version for the devices with the 64KB limit as well.
• Include a Main Menu within every application. In addition to all of the application specific requirements, the main menu must include an option for Help, About, and Exit.

http://www-106.ibm.com/developerworks/library/j-jtp01274.html
Writing garbage collection-friendly classes (Page last updated January 2004, Added 2004-04-29, Author Brian Goetz, Publisher IBM). Tips:

• You only need to avoid creating temporary objects in the most performance-critical situations in the latest JVMs.
• The JIT can use a technique called escape analysis which can recognize that no reference to an object leaves a method. Knowing this, the JIT can then allocate the object on the stack instead of the heap or, even better, optimize the allocation away completely and simply hoist the fields of the object into registers.
• JVMs that use thread-local heaps (IBM, Sun, ...) can avoid globally synchronizing some object allocations, making object allocation faster.
• Finalizeable objects (those that have a non-trivial finalize() method) are both slower to allocate and slower to garbage collect.
• When the object creation cost is high pooling makes sense. Otherwise it seldom does.
• Explicit nulling is only useful when objects are scoped more broadly than they should ideally be, or to avoid object leaks (e.g. dereferecing elements in a collection).
• Explicitly calling System.gc() cam make performance worse: Use the -XX:+DisableExplicitGC option to prevent explicit calls to System.gc() from running a garbage collection.
• Performance advice is highly situational, i.e. it should be tested for your particular application and environment, not applied blindly.

http://www.sys-con.com/WebSphere/article.cfm?id=470
Transactions in WebSphere 5.0 (Page last updated February 2004 , Added 2004-04-29, Author Kyle Brown, Publisher Websphere Journal). Tips:

• Assume that the container will optimally handle autocommit, local versus global transactions, and phase commit optimizations.
• XA enabled resources: if there may be more than one participant in a transaction (this could be two JDBC databases, or a database and a JMS connection or EIS connection, or any other combination); or if an EJB needs to access another EJB deployed in a different EJB container
• The main problem with the pessimistic approach is the waiting for locks to be released: it can lead to unacceptable runtime performance.
• The major advantage of optimistic concurrency control is that since it doesn't require locking, it allows for much better throughput at the cost of some number of aborted updates when collisions occur.

http://www-106.ibm.com/developerworks/library/ws-best9/index.html
Web services performance considerations, Part 1 (Page last updated February 2004, Added 2004-04-29, Author Holt Adams, Publisher IBM). Tips:

• Performance of a Web application is measured by: URL request response speed; concurrency capability; latency in responding to requests; scalability of a solution to handle growth in demand; and levels of operational degradation due to increases in transaction loads.
• Requirements should include quantified acceptable performance criteria,including number of users, and number of simultaneous requests and transactions to be completed within given periods of time.
• The architecture should enable the performance requirements to achieved, and that performance is predictable.
• RMI/IIOP provides significantly better performance than SOAP/HTTP.
• Minimize the number of requests a consumer makes in order to accomplish a set of business tasks.
• The three most common bottlenecks in today's Web services-based solution are related to: Parsing of SOAP messages; Marshalling and un-marshalling of Objects to XML and XML to Objects; Processing of WS-Security capability that includes XML Digital Signatures and XML Encryption.
• Optimizing your Web service performance by keeping your payload (XML exchange documents) small and simple.
• Architect your programming objects to minimize the size and complexity of the XML message structures. But fewer larger more complex messages are usually better than many small simple ones.
• Parsing XML messages take an average of between 20% to 35% of the processing time of simple business functions.
• Use partial parsing of SOAP messages.
• SAX is more efficient than DOM when the resulting object model is simple, resulting in faster parsing by SAX.
• It is recommended that if you use the Xerces parser that you ensure you have the most recent version (V2.6.0 versus 1.4.0) as significant performance enhancements have been included over the past year.
• Be selective in what Business Object Document you use.
• Maximize the amount of real information that's being exchanged: messages with many elements and attributes and little data are usually the result of complicated XML Schemas.
• Enabling security through WS-Security technologies is at least twice the cost of proving similar capabilities using traditional SSL with HTTP.
• Once you have an operating service, follow an iterative process to fine tune your service by measuring simulated loads and adjusting then measuring again to understand the change.

http://www-106.ibm.com/developerworks/library/ws-best9/index.html
Web services performance considerations, Part 2 (Page last updated March 2004, Added 2004-04-29, Author Holt Adams, Publisher IBM). Tips:

• If your solution doesn't require the J2EE runtime support for transaction, security, and management that's enabled through the use of EJB components and the EJB container, then JavaBeans will suffice and will provide better performance.
• If you're using EJB components and deploying them locally within the same JVM as the SOAP engine, then ensure that you deploy them using pass by reference [local interfaces].
• If performance is a high priority do not enable message validation through the parser, instead have the code that processes the parameters validate their values.
• Cache for read-only services or delivery of relatively static content.
• Caching can be applied separately to: SOAP Action; SOAPEnvelope; Port component; SOAP operation; SOAP operation parameters. Components that do not require parsing of the SOAP Envelope will provide the best performance gains.
• UDDI queries can add significant path length to a request and, if done for every request, can degrade a client's performance. Cache the UDDI result access points in a proxy.
• The application tuning parameter hot list is: Hardware and capacity settings; Java virtual machine heap size; Application assembly performance checklist; Data sources connection pool and prepared statement cache; Solaris operating system TCP_TIME_WAIT_INTERVAL; Pass by value/Pass by reference; IBM HTTP Server access logs; HTTP keep alive connections; Transaction logs; Object Request Broker FragmentSize.

http://today.java.net/pub/a/today/2004/03/01/jsr166.html
Concurrency Utilities (Page last updated March 2004, Added 2004-04-29, Author Brian Goetz, Publisher java.net). Tips:

• JDK 1.5 includes System.nanoTime() for measuring nanosecond-precision times if available on the system.
• JDK 1.5 includes a low-level compare-and-swap facility for lock-free algorithms, a class of algorithms that has much more attractive scalability characteristics than those based on using locking (e.g., via synchronized) to protect shared data.
• JDK 1.5 includes concurrent queue classes: ArrayBlockingQueue (a fixed-sized, bounded FIFO queue), PriorityBlockingQueue (a priority queue), and ConcurrentLinkedQueue (an unbounded non-blocking FIFO queue); ConcurrentHashMap (scalable replacement for Hashtable) and CopyOnWriteArrayList (List implementation optimized for the case where iterations greatly outnumber insertions or removals); A flexible task dispatching framework based on util.concurrent.Executor, including a flexible thread pool and a scheduling service; A new, high-performance Lock class, which supports timed lock waits, interruptible lock attempts, lock polling, and multiple wait sets via the Condition class; Atomic variables (AtomicInteger, AtomicLong, AtomicReference): Higher-performance analogues of util.concurrent.SynchronizedInt and friends; Several general-purpose synchronization utilities, such as Semaphore (Dijkstra counting semaphore), CountDownLatch (allows one thread to wait for a set of operations in other threads to complete), CyclicBarrier (allows multiple threads to wait until they all reach a common barrier point), and Exchanger (allows to threads to rendezvous and exchange information);
• In JDK 1.5 the Thread class now supports setting an uncaught exception handler (which previously was only available through ThreadGroup)
• ConcurrentHashMap is designed for thread safety, and for highly concurrent access.
• ConcurrentHashMap supports an unbounded number of concurrent read operations and up to 16 concurrent write operations with no locking.
• The Lock class (sometimes called try-locks), which has similar semantics to synchronized but offers higher performance and additional features, such as the ability to interrupt a thread waiting for a lock, attempt waiting for a lock for a specified time, poll for a lock's availability, or structure lock acquisition and release in a non-lexically-scoped manner.

http://dev2dev.bea.com/products/wlplatform81/articles/thread_dumps.jsp
Thread-Dumps (Page last updated January 2004, Added 2004-04-29, Author Alexandre Rafalovitch, Publisher BEA). Tips:

• Every JVM comes with an ability to generate a thread-dump that shows the state of all threads at that point in time.
• Take five thread-dumps 30 seconds apart and you can see which threads are moving, which are stuck waiting for a global synchronized method, and which ones are stuck in the eternal deadlock.
• [Article discusses analyzing XML transformed stack dumps].

http://www.adtmag.com/article.asp?id=8931
Rory Herriman on remote performance management (Page last updated February 2004 , Added 2004-04-29, Author Programmers Report Staff, Publisher ADTmag). Tips:

• Employ operational tools that allow you to proactively monitor your remote sites and identify potential problems before they become service impacting to the end user.
• Applications should be architected and designed for maximum performance and usability and uniquely tuned for the targeted environment.
• Developers should think things through from the user's perspective.
• Highly distributed environments with multiple, low-speed WAN links like those often found in banking, retail and insurance organizations, require a different application deployment strategy then consolidated, high-speed environments do.
• Session management, transaction profile and communications thread usage are critical performance areas.
• You must design applications to handle peak periods.
• Availability is binary: on or off. Usability includes responsiveness and performance consistency. High availability does not equal high usability!
• Focus on and measure "usability-"oriented metrics.
• Each component must be tuned for the specific environment and performance needs. There is no "one size fits all"

http://otn.oracle.com/tech/java/architect/mwa_week7.html
Multi-Tier Tuning (Page last updated March 2004, Added 2004-04-29, Author Allan Edwards, Publisher Oracle). Tips:

• Connection pools can have resource leaks - such as connection leaks, memory leaks, and cursor leaks - which can cause a production application or environment to fail.
• Look at the whole application, not just subcomponents.
• Make sure you have the benefit of performance facts with historical perspective: what the work flows have been, how much work has been done, how high the resource consumption has been. Comparing current performance to historical performance is extremely helpful in determining performance problems.
• Ninety percent of the time you can greatly reduce the resource consumption just by tuning the SQL itself.
• Look at the amount of logical I/O to see the cost of an SQL statement.
• Tune SQL statements that are run often rather than targeting infrequently run statements.
• Tuning SQL statements includes changing the application operation to avoid needing to issue the statement at all.
• Creating an index is a good tuning option, but be aware that you may be benefiting one SQL statement at the expense of another one, and you're introducing overhead every time data is entered and updated and deleted.
• Cache data which will be reused.
• Use connection pools and prepared statements.
• Isolate the time spent in each layer for particular requests to identify where the bottleneck is.
• Consider tuning and monitoring issues at the architectural design stage.

http://www.onjava.com/pub/a/onjava/2004/03/10/quartz.html?page=1
Job Scheduling in Java (Page last updated March 2004, Added 2004-04-29, Author Dejan Bosanac , Publisher OnJava). Tips:

• For reports that are not needed in real time, schedule report creation for times when the system is idle, or at least when the load on the database system is minimal and cache the reports.
• Use the java.util.Timer and java.util.TimerTask classes to schedule tasks [Article rpvides an example].
• [Article discusses the OpenSymphony Quartz Job Scheduler, an advanced scheduler implementing Cron features].

Jack Shirazi

Back to newsletter 041 contents