-
Plumbr joins flyweight class – version 1.2 is out.
It has now been three months since the last major release. We have not been sitting on our hands - quite the contrary. The main focus of the release was to reduce performance overhead posed by our solution. Numerous customers have asked us about the actual overhead our tool poses. And the second subset of our customers was not happy with the performance impact we posed so far. So we listened and started measuring. And optimizing. And measuring again. As the topic proved to be far more difficult and interesting than we originally imagined, we also covered the lessons learned in our blog posts - available here, here and here.
Filed under: Product Updates
-
Making the right decisions when optimizing code
You have an optimization task at hand. Which is great, now you can do something interesting besides implementing yet another invoice processing screen. The optimization task is (hopefully) linked to some non-functional requirement, such as the number of transactions your application has to process per second or the maximum time per transaction allowed. Now, you have an identified the part of your application as the source of the performance problem. This part of your application uses a particular algorithm. You are considering switching this to another implementation and want to measure the performance impact. As discussed in one of our previous articles, you wisely choose the number of user transactions per second as the metrics to measure. You run your stress test with old implementation, write down the number of operations per second achieved, then run the very same stress test with new implementation, write down new number of operations per second.
Filed under: Performance
-
Measuring memory overhead in Java
I have spent a lot of time recently measuring Plumbr’s overhead and figuring out some ways of reducing it. When I started the measurements, I was frustrated to the extent that I had to let my feelings out in a form of a previous blog post. But now I am back in my constructive mode and ready to share more insights on the subject. How do you measure memory overhead of a Java agent? The answer, as seen below, seems trivial at first: “You measure memory consumption of the application with that agent and without it, then compare”.
Filed under: Memory Leaks
-
Who is stealing your memory? The Application Servers Edition.
You create an amazing app. You put it into production. And you notice that you just do not have enough memory available. Even when all your measurements (maybe taken with the help of our small utility) show that you should be just fine. We are planning to publish a series of blog posts investigating where the heap disappears, and kick off with the infrastructure edition. The hypothesis for today - could my application server be the greedy bastard consuming all my precious memory?
Filed under: Memory Leaks
-
What’s your overhead?
“What’s your overhead?”. We often hear this question when we talk about Plumbr. Wikipedia describes overhead as “any combination of excess or indirect computation time, memory, bandwidth, or other resources that are required to attain a particular goal”. When you dig further in the Internet, you see mostly CPU overhead and memory overhead being mentioned. That is why we can probably translate the question posed in the title into “how much more memory and/or how many more CPU cycles are utilized by my application when run with Plumbr attached?”. After having spent four weeks on trying to measure Plumbr overhead as precisely as possible, I have got a bunch of numbers under my belt. Unfortunately though, it seems that none of them makes much sense in the real life.
Filed under: Performance
-
Why can’t I turn off the Garbage Collector?
Let’s start with a quick rewind to the early days of my career as a Java developer. I wanted to eliminate Garbage Collection (GC) pauses from a test that I was conducting. Lo and behold I was annoyed when I discovered that it couldn’t be done. Back then I left the issue for a “design error” and moved on with my life. Angry at James Gosling or whoever was responsible for the decision. A couple of days ago I ran into a situation that reminded me of those old times. Luckily, the years gone by have accumulated some insight about JVM internals in me, and I thought I’d share my current thoughts in a form of a blog post.
Filed under: Garbage Collection
-
How much memory do I need (part 3) – measure, don’t guess
What looks like as an easy task can in reality become somewhat complicated. There is a whole lot of different aspects you have to bear in mind when calculating the memory footprint of your objects. Such as - do I need to measure shallow or retained heap size? Or do I make the calculations for 32 or 64bit architecture? Or what about the fact that I am running on x86, SPARC, POWER or on something even beyond imagination?
Filed under: Memory Leaks
-
How much memory do I need (part 2) – What is shallow heap?
What is the size of a particular data structure? "Can I fit all these objects into my ehCache?"
Filed under: Memory Leaks
-
Plumbr does not find a leak? Our team to the rescue!
We are confident that we have created a good product. Plumbr has detected hundreds of leaks in very different Java apps all around the world. However, we really like to put our money where our mouth is, so we thought it’s time to raise the bar even higher. From now on: If Plumbr fails to detect an existing memory leak in your application, our team will find it for you! As simple as that. If our tool is not good enough then we have to make our hands dirty. No hidden tricks here.
Filed under: Plumbr
-
How much memory do I need (part 1) – What is retained heap?
How much memory will I need? This is a question you might have asked yourself (or others) when building a solution, creating a data structure or choosing an algorithm. Will this graph of mine fit in my 3G heap if it contains 1,000,000 edges and I use a HashMap to store it? Can I use the standard Collections API while building my custom caching solution or is the overhead posed by them too much? Apparently, the answer to the simple question is a bit more complex. In this post we'll take a first peek at it and see how deep the rabbit hole actually is. The answer to the question in the headline comes in several parts.
Filed under: Memory Leaks