-
Common benchmarking pitfalls
Every once in awhile each and every one of us is trying to measure performance of certain parts of the code. It can be either a fully functional application measured against specific number of user transactions per minute or a microbenchmark. Which you have written to prove that your fellow developer is wrong. Especially in the latter case it is beneficial to be aware of the pitfalls skewing your benchmark results. Looking into the benchmarks I have created in the past I have to admit I was actually incorrect. But I have learned something along the way and think it is worth sharing.
Filed under: Performance
-
How expensive is a method call in Java
We have all been there. Looking at the poorly designed code while listening to the author’s explanations about how one should never sacrifice performance over design. And you just cannot convince the author to get rid of his 500-line methods because chaining method calls would destroy the performance. Well, it might have been true in 1996 or so. But since then JVM has evolved to be an amazing piece of software. One way to find out about it is to start looking more deeply into optimizations carried out by the virtual machine. The arsenal of techniques applied by the JVM is quite extensive, but lets look into one of them in more details. Namely method inlining. It is easiest to explain via the following sample:
Filed under: Performance
-
Cryptic error messages in Java
We are dealing with complex stuff in Plumbr. Hacking JVM internals, bytecode manipulation, data mining - we are all over it. But some of us also teach young developers. Who are doing their first steps in the Java wilderness. And year after year we see those youngsters run into the same problems over and over again. And part of those problems seems to be related with the cryptic ways Java has chosen to explain developers about the problem at hand.
Filed under: Java
-
Amdahl’s law illustrated
The article will explain in simple terms the Amdahl's law. We are going to demonstrate via a case study how throughput and latency are changing when you change the number of threads performing the tasks. We also help to draw right conclusions in the context of your own performance tuning task at hand.
Filed under: Performance
-
How to shoot yourself in foot with ThreadLocals
It will start nicely. Like most of the stories. You discover a new concept and are amazed by it’s powers. And then equipped with this new hammer suddenly everything starts to look like a nail. From what we have experienced in past months, java.lang.ThreadLocal makes one hell of a hammer.
Filed under: Locked Threads
-
How many threads do I need?
If you wish to squeeze out most from all those expensive cores you have purchased for your production site – bear with me and I will shed some light on the mysteries surrounding multi-threaded Java applications. The content is “optimized” towards the most typical Java EE application, which has got a web frontend allowing end users to initiate a lot of small transactions within the application. And significant part of each transaction is kept waiting for some external resource. Such as a query to return from the database or from any other integrated data source. But most of the content is also relevant for other applications. Such as computation-heavy modeling applications or data-chugging batch processes.
Filed under: Locked Threads
-
Selecting your Collections library
Is this really something you should bother? Is there something fundamentally wrong with java.util.ArrayList and java.util.HashMap? For most of the source code out there the answer is - no; those implementations are perfectly OK. But as always, the devil is in the details. And there exist situations when either the feature set built into the Collections API is not sufficient enough or you find the overhead provided by the standard collections to be way too high for your likings. In the past years we have continuously stumbled upon the very same problems. And thought it would be nice to share the experience – hopefully it can save somebody a day or two. Either via avoiding yet another bidirectional Map implementation or understanding why his HashSet consumes 10x more memory than intended.
Filed under: Memory Leaks
-
Looking back to 2012
This one is going to be one of the rare non-technical post. But we just closed our first year and did an internal review of what did we manage to deliver throughout 2012. So our technical readers - do not be afraid. We continue with in-depth technical articles throughout 2013. When we were done with Plumbr 2012 review, it looked like something we could also openly publish. So here we go, hopefully those of you building your own tech company can learn a thing or two from the next 900 words.
Filed under: Plumbr
-
Plumbr now verified to work on Jelastic
Modern technology is wonderful. Looking back to the early 2000’s, it seems ridiculous. We literally had to wait for months to get our hands on a new staging environment. Young developers, you should be grateful for virtualization and IaaS! You can now get happily up and running on a brand new application server within minutes. Or, so the platform providers promise. We wanted to test this promise and see whether it’s really that easy to build a virtualized environment. And, of course, run our very own Plumbr leak detector on it.
Filed under: Product Updates
-
A 12-year-old bug in JDK, still out there leaking memory in our applications
This story goes back. For weeks or even decades, depending on how you mark the starting date. Anyhow, few weeks ago one of our customers had problems with interpreting a leak reported by Plumbr. Quoting his words “It seems that Java itself is broken”. As a matter of fact, the customer was right. Java was indeed broken. But let’s check the case and see what we can learn from it. Lets start by looking into the report generated by Plumbr.
Filed under: Memory Leaks
