-
Plumbr 1.4 released – more support for different platforms
We are now announcing the public availability of Plumbr 1.4. In this version we focused on compatibility and stability issues. The biggest news in the release is Solaris support - Plumbr now works both on x86 and SPARC architectures. We have conducted a month of beta testing and can now proudly present the results. All of you who contacted us via different support channels asking for the Solaris support were already notified, but if you are one of the silent guys then - go ahead and download the newest release.
Filed under: Product Updates
-
Debugging a dying Eclipse instance
The story starts with our decision to go to Devoxx. With a booth. By a caravan. Driving 2,200 kilometers. But this is not going to be a travel story, do not worry. During the travel we taught our marketing guys to be prepared for doing demos in our booth. After all, what’s the benefit of dragging all the droids to Antwerp if they are not even good for a demo or two. As we had ~30 hours of driving time ahead of us, we thought we have enough time to get the droids up to speed. First stop – verifying the required infrastructure. One of the droids had managed to install a JDK and Eclipse all by himself. So far so good. But when firing up the Eclipse and adding our demo project resulted in CPU usage jumping to 100% and Eclipse becoming completely unresponsive.
Filed under: Garbage Collection
-
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
