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!

Back to newsletter 121 contents

http://searchsoftwarequality.techtarget.com/Video-Expert-describes-the-evolution-of-APM-tools-trends-and-challenges
Application performance The intersection between business and technology (Page last updated May 2010, Added 2010-12-28, Author Theresa Lanowitz, Publisher SearchSoftwareQuality.com). Tips:

• Performance management is a critical business enhancing requirement in the current world of competing applications
• centralized performance organizations are becoming very useful to provide the expertise of (65% had) 10 people can provide for the whole. The IT organization typically drives the creation of a centralised performance organization, even thoughthe primatry benefit is on the business side.
• performance management is more than just performance testing; it needs the performance team to understand test automation, application architecture, network archtecture, infrastructure, capacity planning, software engineering
• difficulty and cost of managing decentralized performance organizations was the primary reason for moving to a centralized performance organization.
• companies with centralized performance organizations tend to have higher quality maturity levels, and the correlation appears to be due to the move to a centralized performance organization
• 9 steps to building a centralized performance organization: get agreement; collaborate with the business-side; make it fit your company practices; acquire the range of performance skills; get the technology; focus on customer satisfaction; pilot it; promote the results; motivate the centralized performance organization staff
• security and performance are the two major things you need to consider when thinking of using a cloud

http://searchsoftwarequality.techtarget.com/news/1512585/Application-lifecycle-performance-testing-and-monitoring-strategies
Application lifecycle performance testing and monitoring strategies (Page last updated May 2010, Added 2010-12-28, Author Michael Kelly, Publisher SearchSoftwareQuality.com). Tips:

• Performance testing is about developing an understanding of application performance limits and providing evidence to support conclusions.
• Shopzilla redesigned their site to drop page load times 80% producing an increase in revenue from 7% to 12%.
• Netflix enabled gzip compression for plain text components which resulted in a drop in outbound network traffic which in turn drop lowered their bandwidth bill by 43%.
• Develop a working understanding of the business drivers for your application performance to better make sense of the performance goals and objectives
• Develop a suite of tests that can bring to light some of the performance vs cost or revenue tradeoffs in play for your project.
• Performance test results which are phrased relative to the business drivers (e.g. costs or revenues) for the system or application, can create a compelling story for change.
• Get a prioritized list in the language of the business - not technology - of what matters and why in the project so that you can identify where to target performance tests and tuning effort.
• If you can't identify any performance implications to a metric, perhaps you don't need to monitor it.
• Instead of asking "How fast is fast enough?" you should ask "If we want better performance for business metric X, how might we obtain it and what other business metrics might be impacted by making that change?"
• Understand the different usage models for your application e.g. batch modes or end of month processing, so that your test coverage doesn't have big gaps that will only show up in production.
• To help identify where monitoring and alerting might be handy, for each component or business function, ask: What would happen if that failed, and how would I know? How do I know if it is running fast enough, and what are the implications if it slows down?
• On a regular basis, for one or two tests, take the time to track a transaction through every level of the system (database, services, batch jobs, etc...) and get individual timings under load. Look at the profile of the servers while they are processing that transaction. Understand what the impact might be to the end user.

http://www.ibm.com/developerworks/java/library/j-concurrencybugpatterns/index.html
Java concurrency bug patterns for multicore systems: Six lesser known Java concurrency bug patterns (Page last updated December 2010, Added 2010-12-28, Author Zhi Da Luo, Yarden Nir-Buchbinder, Raja Das, Publisher IBM). Tips:

• Well-known Java concurrency bug patterns include double-checked locking, spin wait, and wait-not-in-loop.
• The ++ and similar operators are not atomic operators so even if you are using a volatile variable, you must use a synchronize barrier to apply these (and any) non-atomic operations if mutiple threads can execute the operation - otherwise you have a potential data race which can result in corrupt data.
• Synchronizating on a mutable field is prone to causing inconsistent threading behavior as if the mutable field changes, a new attempt to lock the field is locking a different object from the previous attempts, hence there is no mutual exclusion between these two threads when mutual exclusion is probably intended.
• java.util.concurrent.locks.Lock without a block is never automatically released. If a Lock.lock() invocation does not have a corresponding unlock() invocation on the same instance, the result could be a lock leak. The canonical pattern to use is lock.lock(); try {...} finally {lock.unlock();}
• If you unnecessarily synchronize too large a block of code, you lock out other threads making the code inefficient. Try to synchronize the minimum set of statements, even if this requires more synchronized blocks so that intermediate thread-safe statements can execute outside any synchronized block.
• Combining two statements that are separately thread-safe into an unsynchronized block does not result in a thread-safe block, as the data can change between the two statements executing.
• Prevent symmetric lock deadlock by determining an order among instances, so that when locks of two instances need to be taken together, the order is computed dynamically and determines which lock to take first . Symmetric deadlock can occur when a class has a method that takes another instance of the same class as its argument, that also needs to perform an operation atomically on members of the two instances. The compareTo and equals methods are two good examples.

http://www.theserverside.com/feature/Caching-Scenarios
Caching Scenarios (Page last updated December 2010, Added 2010-12-28, Author Joe Ottinger, Publisher TheServerSide.com). Tips:

• There are four basic strategies for caching: local caching (common), distributed caching (growing), system of record with local storage (rare), and event handling (inappropriate for caching but used nonetheless).
• For memoization - the storage of intermediate and calculated results - local caching is generally fine, although distributed caching is better because it prevents different participating processors from having to calculate the same intermediate results.
• For intermediate data storage, local caching is most commonly used but it often means your data takes too long to retrieve and distributed caching is often more appropriate.
• Performance goes down as you traverse from read-only to read-write, to nonstrict-read-write, to transactional, but the update safety improves as a tradeoff for performance.
• Distribution of a cache has drastic effects because in most cases, synchronization takes time.
• The two basic distributed cache topologies are hub-and-spoke (central server and backup with master copies; multiple clients; the network bandwidth available to the central server is the limiting factor) and mesh (all nodes equal and connected to all others; synchronization can be costly depending on the transaction strategy).

• Non-transactional event handlers that fail for any reason can cause one or more events to be lost entirely.
• Messages should have lifetimes, such that a message is discarded if it's not consumed within a specific amount of time.
• Cache entries normally have lifetimes associated with them.
• Processing over local data is much much faster than over remotely accessed data - so it can make huge sense to move the processing to where the data is, rather than moving the data to the processor. Cleverly partitioning the data improves this even more.

http://www.informit.com/articles/article.aspx?p=1655225
Optimizing Code for Power Consumption (Page last updated November 2010, Added 2010-12-28, Author David Chisnall, Publisher informIT). Tips:

• Every operation of a mobile application consumes power, affecting the device's battery life. Use too much power and people will avoid using your app.
• The most expensive thing to do with a hard drive is start the platters spinning. If the drive is idle for a while, it's using (almost) no power. Many operating systems will put the disk to sleep after a period of inactivity. If you can query the state of the drive, write immediately when the drive is already spinning, otherwise defer writes if it's safe to do so.
• Flash drives takes very little energy to power up and down, but writes take a lot of power, especially when they require an erase. Ideal flash drive operation is sequential writes and random reads. One technique is to append a description of the changes to a file with every save, and then periodically write out the entire file.
• Use the GPU for rendering where available, this is hugely more efficient than using the CPU.
• Cache as much as you possibly can on a mobile device. But running out of memory on a handheld often means that your app gets killed. Where available use a system cache which will be cleared by the phone when memory is low.
• A well-designed application would defer more power intensive instructions to only execute when the device was plugged in.
• Polling is almost always a bad idea if you care about power usage. Replacing the polling with push notifications can give you big power savings.
• Anything that reduces CPU, GPU, and network usage will give you better power efficiency.

http://java.dzone.com/articles/three-common-application
Three Common Application Performance Challenges for Developers (Page last updated December 2010, Added 2010-12-28, Author Bhaskar Sunkara, Publisher JavaLobby). Tips:

• Memory leaks typically happen as a result of improper programming - usually when the developer didn't remove all references to an object.
• Common leaks include forgetting to remove listeners no longer needed, and forgetting to close opened resources.
• Use heap dumps and/or profilers to diagnose memory leaks.
• A heap dump allows you to see which object is holding a reference to the collections.
• Common reasons for badly performing SQL include fields not being indexed and too much data being fetched.
• Object Relational Mappers can cause badly performing SQL.
• The time and resources taken to retrieve data are often orders of magnitude greater than that required to process it - performance considerations should always include the means and ways of accessing and storing data.
• Using "synchronized" prevents threads from obtaining the same object at the same time and prevents data inconsistencies. But Synchronization effectively forces concurrent processing back into sequential execution, so should be used only where necessary.
• The need for synchronization is not related to performance, but to data process requirements. However synchronization affects parallel performance.

Jack Shirazi Back to newsletter 121 contents