Bhaskar Sunkara had the guts to publish "Three Common Application Performance Challenges for Developers" on DZone. The ones he covers are: memory leaks, slow SQL, and thread synchronization. Same story, different day: none of these are surprising but people haven't gotten the message.

Memory management is the same old chestnut about not leaking object references. He points out that heap dumps and profilers can help you track them, but in production, it's harder to find leaks; he points out transaction and code path analysis as a way to help find these, but doesn't mention products like JXInsight or dynaTrace, which exist for this exact purpose (tracing performance issues in production environments without killing performance.)

Slow SQL is his next point, and he says that indexes and too much data being fetched are major problems. Then he says that an ORM stands out to kill performance. He contradicts himself a little here, to me, because pointing out an ORM as a performance problem isn't the same as blaming a stupid DBA for setting up tables wrong or blaming a dumb developer for retrieving too much data or, issuing too many SQL calls.

The main thing to get from this, though, and he's right, is that getting data can be slow. Use Ehcache or memcached to save data, if you can, although ehcache and company add extra code to your reads and writes. Also, factor in network time to your database calls.

The last thing he covers: threads. He doesn't really give advice here, partly because the subject's not simple, I guess; he mentiones Software Transactional Memory Systems, which I don't really understand, and doesn't mention Java Concurrency in Practice. I think Azul Systems uses something like this, but I don't know how.

Some STM links: Wikipedia, Oracle (although the Oracle link is from Sun, 2007). I'm still not really sure I understand them.

Interesting article. It's sort of the same old stuff, we see stuff like this all the time. But at the same time, we see Java developers who don't seem to be aware of it, so the the signal has to be repeated. You can't stop the signal, Mal.

With regard to memory mgmt a much more common issue in production is insufficient (concurrent/working) capacity exceptions. These are not necessarily leaks but more so workload mgmt related due to the excessive working set requirements for multiple concurrent threads of execution with varying capacity requirements that during the lifetime of a request are held by one or more stack frame or thread local references. These are much harder to solve because they do require some kind of call traffic throttling to be built into the application or container runtime itself that understand such differences.

Tip: Doing a complete heap dump in any production environment outside of a hello world or petstore webapp is a last desperate act that is more than likely going to kill the patient if not induce much more serious issues. I have yet to see this scale outside of a dev environment.

Tip: If you have fast build up in memory consumption and leakage a less drastic measurement mechanism is gc measurement. If a particular person (method) is always at the crime scene (gc collection time interval) then the chances that person is in some way responsible.

I should have added that one way to resolve memory capacity issues which generally manifests in threads throwing OutOfMemory errors but the process still being able to continue further request processing is using real-time (virtual) resource reservation which is the basis for our Quality of Service (QoS) for Java applications and part of our Cost Aware Runtime & Services (CARS) initiative.

QoS for Applications (bring router mgmt to Java call sites): http://williamlouth.wordpress.com/?s=QoS

http://williamlouth.wordpress.com/2010/10/04/cars-cost-aware-runtimes-and-services/

The main thing to get from this, though, and he's right, is that getting data can be slow. Use Ehcache or memcached to save data, if you can ..

Not to pick nits, but if performance and scalability are what you're looking for, and you're not willing to trade off HA, then you should be using Coherence.

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

The main thing to get from this, though, and he's right, is that getting data can be slow. Use Ehcache or memcached to save data, if you can ..

Not to pick nits, but if performance and scalability are what you're looking for, and you're not willing to trade off HA, then you should be using Coherence.

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

Ehcache Enterprise will supports all what Cameron mentioned ...

-------

I often see large clients wich use already enterprise products and still have major performance issues due to Garbage Collection pauses. Often the applications are split into 10 to 50 instances so the application heaps are < 4GB each. This is done to reduce the effect of garbage collection pauses (if a low pause time is important to the business ). However, splitting apps is in-efficient and introduces a high operational overhead. 

With Terracotta's new BigMemory for Ehcache one can utilize the 128GB memory in your servers without being punished by long Garbage Collection pauses additionally to the mentioned HA, Performance and horizontal scalability.

Above mentioned solutions are true for memory issues triggered by maintaining large caches.

If an application simply generates a high amount of garbage (such as PDF generation engines or huge and slow XSL transformations) , Azul's Zing Platform can help keeping the GC pauses low whilst using large heap sizes.

Happy New Year !

Ehcache Enterprise will supports all what Cameron mentioned ...

Will versus does. ;-)

And now that it's just another commercial offering, what benefit is there?

Peace,

Cameron Purdy | Oracle Coherence

http://coherence.oracle.com/

That is right, nothing new. Developers anticipate slow/too-many queries by introducing caches - most of the time, home-made caches, often at the beginning of the project - without enough testing and tuning before production, so memory leaks in that caches and of course that caches require synchronization and limits application concurrency.

My opinion is that ORM system has the great benefits to avoid developers to introduce caching too early, it also helps to detect slow queries or too many queries per user request. An ORM system is more manageable than SQL queries and home-made caching all around the application code. When a SQL issue appears, the ORM mapping and query definition helps to fix it faster often without having to rewrite code.

Finally JEE guidelines and patterns are already there to avoid that troubles: no static references in your application code (so no own-made cache), distributed transaction, no synchronization trouble because of one-thread-per-bean (Servlet is an exception and that is a shame), configurable thread pools and monitoring and management tools for production. Everything is there and clear ! No big issue to expect from a well designed JEE application.

By the way, if your application code under a certain load requires CPU and memory you have not (yet), then profiling and code rewrite is necessary and I do not think it should be done on production. With good statistics about users application usage (auditing in DB or logging), it is not so difficult to build relevant load-testing scenario to optimize the code in a test environment.

While the article does well to highlight some of the issues with performance of applications, I think the issue with performance management in today’s complex enterprise systems is more systemic rather than confined to the code itself.  I've seen and been appalled by performance requirements starting and ending with - 'we need the system to perform well' statements.  There are umpteen tools to measure performance, identify bottlenecks and suggest fixes at the software level. However unless there is a process to ‘manage’ performance across the development cycle and unless the architect takes a complete view of the entire architecture (hardware, software, deployment etc) from performance stand-point, the efficacy of these point solutions will be very limited. Again, I don’t intend to take anything away from the author- but, in my view point an architect needs to think much beyond the code to build a system that performs well.

Ashutosh

www.avekshaa.com

Cara Beriklan Di Internet  Contoh Surat Lamaran Kerja  Contoh Proposal