Back to newsletter 097 contents

http://java.dzone.com/articles/caching-parallelism-scalability
Caching, Parallelism and Scalability (Page last updated September 2008, Added 2008-12-30, Author Manik Surtani, Publisher JavaLobby). Tips:

• Since 2005, generally increased computing power has been from increased cores rather than faster cores, which means optimisation is now mostly about improving parallelism in your application.
• Making the most of parallelism involves extra effort; common approaches include: more piecemeal workloads, producer/consumer design patterns, use of efficient concurrency libraries and inter-thread synchronization mechanisms.
• A cache should be a cheaply accessible data structure that allows thread-safe access to in-memory data. It should have features such as eviction and expiration of cached data, and passivation/overflow of in-memory state to a more persistent store.
• A clustered cache instance is aware of other cache instances in a cluster and is capable of synchronizing operations with its peers. Cache contents are typically mirrored.
• A well-written cache minimizes locking and inter-thread signaling, and would use modern techniques such as compare-and-swap to ensure data integrity in a scalable manner.
• Clustered caches employ several mechanisms to maintain synchronization between the caches and ensure data validity is maintained: Pessimistic cluster-wide locks (limits scalability); Optimistic locks (potential retry overheads); Distributing data (needs keeping data synchronized); Clustering for high availability.
• Caches aren't silver bullets and should not be used indiscriminately - "Measure, don't guess." - use a profiler and introduce caches only where necessary, where data retrieval or calculation bottlenecks are hampering scalability.

http://www.javaspecialists.eu/archive/Issue165.html
Starvation with ReadWriteLocks (Page last updated October 2008, Added 2008-12-30, Author Dr. Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:

• ReadWriteLock should only be used in cases where the critical section is at least 2000 code statements
• For most applications concurrency classes such as ConcurrentHashMap and ConcurrentLinkedQueue are more efficient than using ReadWriteLock.
• ReadWriteLock with many readers compared to writesr can cause the write threads to be starved of access to the lock.
• Using fairness et to true in ReentrantLock reduces throughput significantly.
• You should probably never use ReadWriteLocks in Java 5. In Java 6, use ReadWriteLock when you are willing to wait for writers to get an opportunity to acquire the lock - they won't get locked out completely, but it might take some time before they are serviced.

http://www.jgroups.org/memcached/memcached.html
A memcached implementation in JGroups (Page last updated September 2008, Added 2008-12-30, Author Bela Ban, Publisher JGroups). Tips:

• Consistent hashing always maps the same key K to the same server S. When a server crashes or a new server is added, consistent hashing makes sure that the ensuing rehashing is minimal.
• Memcached typically is used to provide a large distributed cache sitting in front of a database.
• PartitionedHashMap is a Java implementation of memcached that: Allows direct local cache access without serialization overhead; Allows migration of keys from one server to another; The type of transport and the quality of service can be controlled and customized through the underlying XML file defining the transport; Exposes management information and operations via JMX.
• PartitionedHashMap has an L1 cache that caches distributed cached data near to where it is really needed.
• Optimal request balancing would direct HTTP requests for static content to a static webserver, and dynamic content to an application server.

http://www.ibm.com/developerworks/web/library/wa-aj-hiperform/
High-performance Ajax with Tomcat Advanced I/O (Page last updated September 2008, Added 2008-12-30, Author Adriaan de Jonge, Publisher developerWorks). Tips:

• A page can poll the server regularly, creating a large number of server requests and a considerable latency between the event and the notification; or it can keep a connection open to the server waiting for a response, which allows the quickest response to events on the server.
• An open connection means a dedicated thread is doing nothing but waiting until it needs to update the client in response to an event. Threads are relatively expensive, and a limited number of threads are available on a server. An increase in the number of concurrent visitors quickly adds to the resource usage on the server. A few hundred visitors leaving their browsers open while they're away from their computers can quickly become problematic - requiring non-blocking I/O for efficient scalable servers.
• You can use Non-Blocking I/O (NIO) to keep a connection open without wasting waiting threads. To facilitate NIO you should use an event-based API that initiates appropriate reading and writing actions on the open connections at the right time.
• For short-lived connections, the classic approach works fine: read until there is no more data, then close the connection - this usually takes little time, so the system resources are claimed for only a short period. This model fails for long-lived connections where a thread per connection is not scalable.
• For connections that will remain open, make sure you flush the data after you're done writing an iteration; otherwise, it may be stuck in a buffer until the next iteration is written to the stream.
• The Servlet 3.0 specification specifies a standardized mechanism for supporting event-based NIO.
• An efficient NIO server request handling mechanism is for one thread to distribute incoming requests as quickly as possible (minimal overhead, does nothing else) to a queue that supplies worker threads asynchronously; worker threads configured to fully utilize the available thread pool; by monitoring the request processing time and the queue size, you can determine if further server resources are required for improved throughput.

http://www.developer.com/design/article.php/3770961
Portal Performance Planning (Page last updated September 2008, Added 2008-12-30, Author Scott Nelson, Publisher Developer.com). Tips:

• If too much focus is put into performance in the planning and design phases, a great deal of effort will be spent on tasks that will have an infinitesimal impact on performance. Try not to over-plan for performance.
• Use a logging API to help pinpoint performance issues, while making sure that the logging itself doesn't become a performance problem.
• Any call to an external system should have a debug log statement. Any internal algorithms that can take longer than a few milliseconds should log at the beginning, the end, and during any heavy calls (all with the debug check).
• Use exceptions for exceptions, not code flow control - otherwise there are likely to be performance issues.
• One trick is to have a singleton (or interface) that contains all such static shared strings.
• "The environment you deploy to will never be the same you develop on." In the context of performance, this means that production is going to contain much larger data sets and a great many more concurrent sessions than you will have when building the code to support production.
• A good rule of thumb is to figure what the edge performance parameters will be in production and double it for your performance testing.
• If you don't have a performance testing environment it is very important that you make it clear to all stake holders that you do not know how the application will perform in production.
• Portals often bring disparate applications together - it shouldn't be a huge surprise if they don't perform well together. Portlets that combine calls to multiple source systems that run beautifully individually can become a huge performance hit when called sequentially. When possible, work with the UI designers and Information Architects to spread these portlets across separate pages.
• Pre-Compile JSPs.

http://www.developer.com/java/ent/article.php/3775016
Improving Portal Page Load Performance (Page last updated October 2008, Added 2008-12-30, Author Scott Nelson, Publisher Developer.com). Tips:

• For page loads, graphics have always been the biggest performance hit and still are.
• Every graphic should be optimized for minimal file size. (An inability to manage this may indicate you are overusing graphics.)
• A graphical bullet point may be give a great impression in a presentation, but most browsers would much rather get to their data points quickly rather than be impressed with how pretty they look.
• Clear spacer images should be replaced with proper CSS. Apart from the extra downloads, clear spacer images can be read into a printer buffer individually, slowing printing.
• Rounded corners do not need images, the same effect can be achieved using nested tables. Nested tables no longer cause performance issues (unless coded badly).
• With web pages, smaller is always better - even if your page is entirely text, you will get a much faster load time if the data sent to the browser is 1/5 the size.
• Compact CSS files by combining common definitions and specifying differences only.
• Total page load time is actually increased using Ajax, but if done correctly by considering what the user is most interested in seeing, the page can appear to load much much faster than it actually does - and faster than a non-Ajax equivalent would seem to load in.
• Use HTML instead of XML with Ajax, if the HTML is smaller.
• If a Javascript script is needed only on a single page (and doesn't need to be obfuscated) it is fine to have it inline, and place it at the bottom of the page, where it loads last - the page will load without evaluating the script before painting the screen. Remember, though, that the script needs to be loaded before the function call that uses it.
• A JS file is fine, so long as it doesn't contain all the functions for the entire site when only a small percentage are used on a per-page basis. Otherwise, break it up or inline the functions as needed.
• YSlow (http://developer.yahoo.com/yslow/) will show you file size and load time for every little thing, it also will give you a grade for each performance aspect of your page.

Jack Shirazi Back to newsletter 097 contents