OKTECH Profiler is an open-source, low-overhead, sampling Java profiler that analyses the stack trace of the running threads as a local Java agent or a remote JMX client. It works without management application (dumps information in a binary file), allowing behind-firewall profiling and late-analysis. Check the project page, the feature list or the announcement blog entry. While I'm fully aware that some people have different ideas on profilers (we used to have those feelings too), I'm requesting the community to ask questions, request features and provide feedback on this profiler tool. These are the things that can focus our development and give us direction.
- Posted by: Istvan Soos
- Posted on: August 19 2009 08:24 EDT
- More competion improves quality by peter veentjer on August 19 2009 09:07 EDT
- Re: Open source Java profiler: OKTECH Profiler by Jess Holle on August 20 2009 07:45 EDT
- 1.0.1 bugfix released by Istvan Soos on August 21 2009 18:06 EDT
Hi Istvan A few of the things I like to see are: - integration with the 'big' idea's like Eclipse, IntelliJ, Netbeans. I use JProfiler for Multiverse (got an open source license) and starting it from my ide saves time. - some nice graphics (I'm a sucker for nice diagrams) and sortable tables. OKTECH only is able to do sampling? Sampling is great to find performance problems because there is not much overhead, but a lot of information is lost. For example the number of calls, and in some cases this is a nice performance indicator as well. So instrumentation can be useful (perhaps you can add dynamic instrumentation so you can zoom in to certain parts of the system?) Peter Veentjer Multiverse Software Transactional Memory
A few of the things I like to see are:I think the itegration in 'small' is possible: in all the IDEs you can set JVM arguments, and you can set the profiler as a Java agent. I could think of more tighter integration later, but now, the build process and the production application are the main targets. Actually e.g. NetBeans Profiler is pretty good in its field, so why compete with him? I like those fancy diagrams too, and it is in our queue, however at the moment we just have 24 hours a day :). I do hope we will have a university student in the following semester who can polish these things a bit.
- integration with the 'big' idea's like Eclipse, IntelliJ, Netbeans. I use JProfiler for Multiverse (got an open source license) and starting it from my ide saves time.
- some nice graphics (I'm a sucker for nice diagrams) and sortable tables.
OKTECH only is able to do sampling? Sampling is great to find performance problems because there is not much overhead, but a lot of information is lost. For example the number of calls, and in some cases this is a nice performance indicator as well. So instrumentation can be useful (perhaps you can add dynamic instrumentation so you can zoom in to certain parts of the system?)We have pretty good experience with instrumentation profiler (actually the previous version of our profiler was built on top of Javassist and used instrumentation), so this is definitely an option. However we have decided to go open source only with our new development in the sampling profiler space, as there was no legal constraints on that part, while the instrumentation part is still debated. I personally would like to see a mixture of the technologies (e.g. best of both worlds), and at least gradually I might introduce parts in open source. But I'm afraid in the near future our focus will be on the statistical part of the sampling: I see a few interesting research topic here, and hope that a graduate student can help us out in these fields :) On the other hand, not everything is about the technology itself, as sampling removes a big operational risk from the production system. You won't get kicked in the ** if you run a low-overhead sampling and that produces you a valuable information. But you will be, if your instrumentation profiler hangs the system and the administrators fight for hours to get things straight again...
Ok, I understand. The focus for OKTECH is the preproduction/production environment and the 'classic' profilers are more suited for test/development environments. How does it compare to other big players in the market like: - Dynatrace - Wiley Intrascope Apart from it being Open Source? Peter Veentjer Multiverse Software Transactional Memory
The focus for OKTECHJust a slight correction, the name is "OKTECH Profiler". It derives from our company name (OKTECH), because we plan to release other products in similar naming style...
The focus [...] is the preproduction/production environment and the 'classic' profilers are more suited for test/development environments.Yes, production profiling, but I'd say profiling the JUnit test belongs to the development environment profiling. This concept (e.g. using the unit tests and profile them as part of the build process) produced interesting feedbacks in some of our cases, so I'd like to emphasize this as part of the build automation process. And actually it gives one more reason to implement unit tests.
How does it compare to other big players in the market like:Not in the same league, definitely. Those are like death stars, while we only have a few tie fighters :). I think if someone is interested in every tiny detail of the application performance, he/she should look for a different, more suited tool for such jobs. We are targeting the ones who have little time, the profiling is just another task in the everyday work, and who are looking for fast results. This doesn't mean the results are useless, it is just we have different profiling scopes.
- Wiley Intrascope
Apart from it being Open Source?I might be wrong, but there is not too much open source Java sampling profiler. There are open source instrumentation profilers out there, but some of the are just outdated with the JVMPI stuff, some of the have difficulties with classloaders in an application server, so we have ended up to write our own...
NetBeans currently has a huge gap -- it cannot do sampling only profiling (except of itself!?!). If you could manage to work with the NetBeans team to plug this gap, that would be *fabulous*. [Yes, NetBeans has a pretty nice instrumenting profiler, but there are issues with real world use without a sampling profiler. It takes a fairly long time to instrument if you have a lot to instrument. Worse, it has a hard limit on how much it can instrument. If you don't know where your problem is and have a lot of code, with NetBeans' profiler you're aboslutely SOL.]
Thank you for the private and public responses! There were two bugs in the configuration handling, so I've just released the 1.0.1 bugfix version. Please feel free to report the bugs and/or further feature requests in the issues. Istvan