 
| View previous topic :: View next topic |
| Author |
Message |
Scott Wells
Posted via mailing list.
|
 Posted: Thu Apr 30, 2009 4:54 pm Post subject: Re: Why is the profiler so much slower than, e.g., YourKit? |
 |
|
Jess Holle <jessh@...> writes:
| Quote: |
Tomas Hurka wrote:
Yes, you should reduce the number classes that need to be
instrumented. You can do it in two ways:
1) select correct instrumentation filer - if you want to profile whole
application, your instrumentation filer should just include classes
from your project. Note that this is done automatically if you use
'Profile Project' and select 'Entire Application'.
2) if you can select just part of your application as root methods -
you can use 'Root method selector' to specify classes, packages or
servlet(s), jsp(s) from your application. If you use 'Entire
Application' with 'Profile Project', root methods are set automatically
to be all your project classes.
This is impractical in many real world cases where you don't initially
know at all where the problem is -- hence the need for a
sampling profiler.
Also there are serious bugs in the UI for specifying root methods (i.e.
the one that operates via dialogs rather than from the source code).
Finally, you don't have to go through all of this in YourKit -- it just
works.
--
Jess Holle
|
I agreed with Jess. In all fairness, I have constrained both the instrumented
classes considerably and specified a narrow set of entry points for
instrumentation, but NetBeans Profiler is still unusably slow against our
server. Against the client it does a decent job, but the set of classes there
is considerably smaller! It's still significantly slower than YourKit, but
usable as a second data point when doing performance analysis.
It sounds like the bottom line is that there's no way to configure NetBeans
today to perform in a manner that's similar to YourKit, i.e., virtually
instantaneous profiling of CPU, memory, threads, etc., with the overhead
introduced based on how much information you're trying to capture and amortized
over actual execution time, not as an impediment to even getting started.
If you haven't done so, you guys might want to pull down a 30-day eval of
YourKit and play with it to see what we mean. While it doesn't currently
support (at least as of the 7.5 version we have) dynamic attach/detach on
arbitrary 1.6 JVMs, once you start a JVM with the YourKit agent, it's trivially
easy to begin gathering diagnostic information.
Thanks for all the replies!
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: address-removed
For additional commands, e-mail: address-removed |
|
| Back to top |
|
 |
Scott Wells
Posted via mailing list.
|
| Posted: Thu Apr 30, 2009 10:56 pm Post subject: Re: Why is the profiler so much slower than, e.g., YourKit? |
|
|
Tomas Hurka <Tomas.Hurka@...> writes:
| Quote: | I think NetBeans Profiler works that way, but you did not provide
enough information so that we can help you with your use-case or
improve future versions of NetBeans Profiler based on your feedback.
Unfortunately it looks like you already make your mind that it is not
possible to configure NetBeans Profiler so that you can profile your
application.
|
Wow...I think you totally misread my comments! I'm not trying to "poo poo" the
NetBeans Profiler or insult anyone. Like I said, I've actually a very big fan
of and evangelist for it. However, I've had very little luck using it to
profile our server application because it hadn't finished instrumenting classes
almost 30 minutes after starting a CPU profiling session for a constrained set
of entry points and instrumented classes whereas the server was responsive
immediately after starting a CPU profiling session when I used YourKit.
Let me ask my question again a different way and see if we can work productively
toward a helpful answer since I do genuinely want one.
I have a server application that's hosted by JBoss and uses a large number of
third-party libraries such as Spring, Hibernate, Jakarta Commons, etc. Between
those third-party dependencies and our own product, we have tens of thousands
(perhaps hundreds of thousands) of classes potentially in play. I have
configured NetBeans Profiler as follows before connecting:
* CPU Profiling
* "Part of application" with a handful of methods used as entry points
* "Filter" with "Exclude Java core classes" (though I've tried significantly
more restrictive filters such as our own product's package name, but if the
problem is in a third-party library or the way we use it, that's not very helpful)
* "Exact call tree, sampled timing, 10ms" (I tried this option hoping it would
help, but it didn't seem to)
* "Exclude time spent in Thread.sleep() and Object.wait()"
* "Profile new Threads/Runnables" (we use both extensively in our app)
* "Instrumentation scheme, Lazy" (I've also tried Eager and Total)
* "Instrument Method.invoke()" (Spring, Hibernate, etc., are heavily
reflection-based, so I definitely want to see that activity)
That's the configuration I tried that ended up instrumenting a HUGE number of
methods over a period of 20-30 minutes before I finally just killed the server
and switched to YourKit which provided information immediately. This is all
against a 64-bit Windows server and a 1.5 JVM process with a very large max heap
size, though the process itself hadn't come close to growing into that heap, nor
would I have expected heap size to be terribly important for CPU profiling.
I'd love it if you could provide guidance on a different way to configure the
profiler that would allow me to start gathering diagnostic data pretty much
immediately (or even just a minute or so) after starting my profiling session.
| Quote: | I am surprised by this offer. Do you really think that we did not play
and evaluate other profilers?
|
No, I assumed you guys had, but given some of the comments and responses I'd
seen I wondered if that were the case. I figured it couldn't hurt to recommend
that you see what I'm seeing (and evidently at least Jess as well) as the
difference between NetBeans Profiler and YourKit in a real world scenario. No
offense intended whatsoever...
---------------------------------------------------------------------
To unsubscribe, e-mail: address-removed
For additional commands, e-mail: address-removed |
|
| Back to top |
|
|
Scott Wells
Posted via mailing list.
|
| Posted: Thu Apr 30, 2009 11:08 pm Post subject: Re: Why is the profiler so much slower than, e.g., YourKit? |
|
|
A little more information that Tomas asked for plus another piece that I forgot
to include. First the answers to his questions:
Q: To help you more I need to know, what type of NetBeans project you use
for your application.
A: I actually don't use NetBeans as my primary IDE, but if I do have my code
loaded into NetBeans when I profile (not often), I using free-form projects.
Q: What setting you use 'Entire Application' or 'Part of Application'?
A: "Part of Application" if I can clearly identify the entry points, but that's
not always possible. Sometimes you're trying to figure out exactly what is
expensive!
Q: Are you doing local or remote profiling?
A: Remote profiling against a JBoss server when I'm seeing these issues. I
can't really perform local profiling against our apps easily based on the
complexity of their deployment.
Q: Do you use 'Profile Project' or 'Attach Profiler'?
A: "Attach Profiler".
Q: Do you use dynamic attach?
A: In the case I've been describing, I'm against JRE 1.5 so I can't use dynamic
attach. However, that leads me to the other piece I'd forgotten to include.
Our product now supports JRE 1.6 so I tried to profile using dynamic attach. It
attaches fine and shows thread information, but as soon as I try to use the
server (well, a few minutes later after it has instrumented a large number of
classes), I get errors like the following in my server logs:
Caused by: java.lang.NoClassDefFoundError:
org/netbeans/lib/profiler/server/ProfilerRuntimeCPUFullInstr
There are many backtraces to that root cause, I assume because it's failing
trying to instrument various pieces of code as they're called.
Let me know if you need additional information,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: address-removed
For additional commands, e-mail: address-removed |
|
| Back to top |
|
|
SCWells72
Joined: 05 May 2009
Posts: 2
|
| Posted: Tue May 05, 2009 2:00 pm Post subject: Bump |
|
|
Hey, Tomas. I thought I'd follow-up and see if you had any additional tips based on the more complete answers to your questions I've provided.
PS: I've moved over to the forums rather than the mailing lists. MUCH better UI! I was "Scott Wells" there and am "SCWells72" here... |
|
| Back to top |
|
|
Tomas Hurka
Posted via mailing list.
|
| Posted: Mon May 11, 2009 2:45 pm Post subject: Re: Why is the profiler so much slower than, e.g., YourKit? |
|
|
Hi Scott,
On 5 May 2009, at 16:00, SCWells72 wrote:
| Quote: | Hey, Tomas. I thought I'd follow-up and see if you had any
additional tips based on the more complete answers to your questions
I've provided.
|
Thanks for the information you provided. I was busy last week and did
not have time to look at it. I will get back to you this week.
Bye,
--
Tomas Hurka <mailto:address-removed>
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.dev.java.net
Software Engineer, Developer Platforms Group
Sun Microsystems, Praha Czech Republic
---------------------------------------------------------------------
To unsubscribe, e-mail: address-removed
For additional commands, e-mail: address-removed |
|
| Back to top |
|
|
Tomas Hurka
Posted via mailing list.
|
| Posted: Fri May 15, 2009 6:33 pm Post subject: Re: Why is the profiler so much slower than, e.g., YourKit? |
|
|
Hi Scott,
On 1 May 2009, at 00:56, Scott Wells wrote:
[..]
| Quote: | * CPU Profiling
* "Part of application" with a handful of methods used as entry points
* "Filter" with "Exclude Java core classes" (though I've tried
significantly
more restrictive filters such as our own product's package name,
but if the
problem is in a third-party library or the way we use it, that's
not very helpful)
* "Exact call tree, sampled timing, 10ms" (I tried this option
hoping it would
help, but it didn't seem to)
* "Exclude time spent in Thread.sleep() and Object.wait()"
* "Profile new Threads/Runnables" (we use both extensively in our app)
* "Instrumentation scheme, Lazy" (I've also tried Eager and Total)
* "Instrument Method.invoke()" (Spring, Hibernate, etc., are heavily
reflection-based, so I definitely want to see that activity)
That's the configuration I tried that ended up instrumenting a HUGE
number of
methods over a period of 20-30 minutes before I finally just killed
the server
and switched to YourKit which provided information immediately.
This is all
against a 64-bit Windows server and a 1.5 JVM process with a very
large max heap
size, though the process itself hadn't come close to growing into
that heap, nor
would I have expected heap size to be terribly important for CPU
profiling.
I'd love it if you could provide guidance on a different way to
configure the
profiler that would allow me to start gathering diagnostic data
pretty much
immediately (or even just a minute or so) after starting my
profiling session.
|
If the setup is correct, there should be minimal overhead, until the
root method is hit. So what you are experiencing is definitely not
right (AFAICT). Can you please use
1) Part of application" with a handful of methods used as root methods
(how many methods you have?)
2) "Filter" with "Exclude Java core classes" and use your own
product's package name
3) "Exact call tree" - no sampled timing - this will not reduce the
number of instrumented classes
4) "Exclude time spent in Thread.sleep() and Object.wait()"
5) Disable "Profile new Threads/Runnables". "Profile new Threads/
Runnables" means that every run() method from Runnable interface is
automatically set as root method. You don't want to use it in this
situation.
6) "Instrumentation scheme, Lazy"
7) "Instrument Method.invoke()"
It would be nice if you can send me NetBeans' message.log and JBoss
log file from such profiling session. This way we can get some more
information, what is going on.
Thanks for helping us improve the NetBeans Profiler.
Bye,
--
Tomas Hurka <mailto:address-removed>
NetBeans Profiler http://profiler.netbeans.org
VisualVM http://visualvm.dev.java.net
Software Engineer, Developer Platforms Group
Sun Microsystems, Praha Czech Republic
---------------------------------------------------------------------
To unsubscribe, e-mail: address-removed
For additional commands, e-mail: address-removed |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
