-
Do you get Just-in-time compilation?
Remember the last time when you were laughed at by C-developers? That the Java is so slooooow that they would never even consider using a language like this? In many ways, the concept still holds. But for it’s typical usage - in the backbones of a large enterprise - Java performance can definitely stand against many contestants. And this is possible mostly thanks to the magical JIT.
Filed under: Java
-
What does it take to support Solaris?
Java is a cross platform runtime. You write your code on a platform of your choice, test it on a different platform and then push it into production on a third platform. It just works. You do not think about the differences under the hood - JVM implementations take care of it. On worst case scenario you need to tweak some minor differences once in a blue moon. For example when building Plumbr we have only a single Ant target that takes care of producing a Plumbr executable. On any platform we supported so far.
Filed under: Plumbr
-
Increasing heap size – beware of the Cobra Effect
The term 'Cobra effect' stems from an anecdote set at the time of British rule of colonial India. The British government was concerned about the number of venomous cobra snakes. The Government therefore offered a reward for every dead snake. Initially this was a successful strategy as large numbers of snakes were killed for the reward. Eventually however Indians began to breed cobras for the income. When this was realized the reward was canceled, but the cobra breeders set the snakes free and the wild cobras consequently multiplied. The apparent solution for the problem made the situation even worse. So how is Java heap size related with Colonial India and poisonous snakes? Bear with me and I’ll guide you through the analogy using a story from a real life as a reference.
Filed under: Memory Leaks
-
Want to go to Devoxx? Get your free pass from Plumbr!
We are going to Devoxx this year. In case you haven’t heard of it - this is the biggest Java event in Europe with approximately 3000 attendants. The event is held in Antwerp, Belgium from 12th to 16th November. The good part with all this Devoxx fuss is that - we have some Devoxx passes waiting for you. If you haven’t bought yours - the conference is sold out and this might be your last chance to attend.
Filed under: Plumbr
-
Slow death – the cause and the remedy
Another day in the office. Except that you have just realized that the application at your guard seems to take forever to respond to requests. Operations which usually take just few hundred milliseconds to complete are now slower than snails on Xanax. This weird situation gradually worsens throughout the next hours. You manage to discover that the CPU usage is unusually high. Before you have time to dig further you have to surrender to the boss breathing down your neck. You restart the application on his demand. Only to discover the Xanax guys to return within half an hour. This time you decide to stand your ground and find out the cause. Monitoring tools show high CPU usage and quick growth in memory consumption. In conjunction with quickly decreasing throughput. You plot the data on a graph and see the following trend taking shape:
Filed under: Garbage Collection
-
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
© Copyright Plumbr. All Rights Reserved.