Measuring elapsed time?
-
- Posts: 3
- Joined: Mon Jun 06, 2005 1:07 am
Measuring elapsed time?
Yourkit is useful when I want to measure CPU time, but if I could measure elapsed time instead it would be a good starting point for DB tuning. Is there any way of measuring elapsed time with yourkit?
Thanks,
Tom
Thanks,
Tom
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Thanks for the suggestion.
Could you please provide more specific detail of what kind of things you would like to measure.
I think it is reasonable to measure elapsed time not for all methods, but only for the specific ones. For example, I/O and JDBC calls, that can be real bottlenecks but do not consume CPU. For all other methods their CPU times are more interesting.
Are you agree with this?
Could you please provide more specific detail of what kind of things you would like to measure.
I think it is reasonable to measure elapsed time not for all methods, but only for the specific ones. For example, I/O and JDBC calls, that can be real bottlenecks but do not consume CPU. For all other methods their CPU times are more interesting.
Are you agree with this?
-
- Posts: 5
- Joined: Thu Oct 06, 2005 5:28 pm
True, but the I/O calls are not the interesting points, but the methods that contains them -- specially if they're found in a third party library. How would YourKit figure out which methods measure? How to group them?Anton Katilin wrote:I think it is reasonable to measure elapsed time not for all methods, but only for the specific ones. For example, I/O and JDBC calls, that can be real bottlenecks but do not consume CPU. For all other methods their CPU times are more interesting.
I think it's safe to say that we developers are best at this task -- let YourKit measure the elapsed times for all methods (taking filters into account), and let us figure out the bottlenecks.
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Previous version had elapsed times "for all methods". Many users were confused with the results. There were non obvious issues with it.
For example, all standard file and socket I/O, database calls (e.g. Statement.executeQuery()) etc.
If a 3rd party library uses standard calls as a background, this approach should work for it.
If there's something absolutely non standard, appropriate methods can be included to that list by user.
Also, in the next version we consider adding of higher level groupping of results to simplify e.g. DB calls profiling.
This can be done basing on some (pre-)configured lists of interesting methods.How would YourKit figure out which methods measure? How to group them?
For example, all standard file and socket I/O, database calls (e.g. Statement.executeQuery()) etc.
If a 3rd party library uses standard calls as a background, this approach should work for it.
If there's something absolutely non standard, appropriate methods can be included to that list by user.
Also, in the next version we consider adding of higher level groupping of results to simplify e.g. DB calls profiling.
-
- Posts: 5
- Joined: Thu Oct 06, 2005 5:28 pm
This assumes the user knows which methods are interesting. What if we're starting from nothing? Take, for example, the usual "the application is slow" scenario: I would have to profile it first (and check the elapsed times) to find out that calls to a certain third-party library are taking too long.Anton Katilin wrote:If there's something absolutely non standard, appropriate methods can be included to that list by user.
I'm in this situation right now, while evaluating YJP. One of my applications is slower than it should be, and all I could figure out that the bottleneck is definitely I/O; a snapshot spanning 15+ minutes shows only a few seconds of CPU time. Short of sprinkling the code with System.currentTimeMillis() around every I/O-intensive method, I have no idea where exactly the bottleneck is.
-
- Posts: 3
- Joined: Wed Sep 07, 2005 8:48 am
+1! This is very important to have for distributed calls, too. If a thread does direct socket calls (e.g. JDBC driver) you can see the timings ok, but an ORB that multiplexes multiple calls over one connection (all CORBA implementations do that) the pattern looks as follows:
When profiling this, the app thread will have almost 0% CPU, the ORB thread will have around 100%. Not helpful. I would like to see how long call() needed to wait for a reply. If you could have both "CPU" and "wall clock" time or either one based on a filter that would be great!
Code: Select all
App thread:
stub.call():
response = orb.send(oid, "call")
while(!response.received()) response.wait();
return response.result();
ORB response reader thread:
while true:
requestId,result = readFromSocket();
response = pending.remove(requestId);
response.setResult(result);
response.notify();
-
- Posts: 3
- Joined: Mon Jun 06, 2005 1:07 am
It's not obvious to me what the issues wereAnton Katilin wrote:Previous version had elapsed times "for all methods". Many users were confused with the results. There were non obvious issues with it.
I'd simply like elapsed time and CPU time side-by-side on each method (or I'd be equally happy choosing one or the other at the time I started the snapshot).
-
- Posts: 1
- Joined: Thu Nov 24, 2005 7:48 pm
CORBA Tracing and Profiling Article
Hi,
Here is a link on how to profile CORBA applications. It is also possible to have transaction correlation across multiple JVM's.
http://www.jinspired.com/products/jdbin ... acing.html
Regards,
William
Here is a link on how to profile CORBA applications. It is also possible to have transaction correlation across multiple JVM's.
http://www.jinspired.com/products/jdbin ... acing.html
Regards,
William
-
- Posts: 5
- Joined: Tue Aug 09, 2005 11:36 pm
What's the status on this?
Is this something being implemented? I have an application
that calls a method which takes 60 seconds (print out time spent
using System.out.println) but YK only shows 23
seconds used by CPU. Elapsed time would be more useful, so
you can dig into what is really slow, not just what consumes the
most CPU.
So, no matter if a thread is running or sleeping, please caputure the
times spent... I'm sure most of your users would appreciate this
feature as well. So, please, please, please add this feature
Thank you.
that calls a method which takes 60 seconds (print out time spent
using System.out.println) but YK only shows 23
seconds used by CPU. Elapsed time would be more useful, so
you can dig into what is really slow, not just what consumes the
most CPU.
So, no matter if a thread is running or sleeping, please caputure the
times spent... I'm sure most of your users would appreciate this
feature as well. So, please, please, please add this feature
Thank you.
-
- Posts: 21
- Joined: Tue Dec 13, 2005 2:53 pm
I need elapsed time measures for LDAP queries
I could really use elapsed time measures also. My application involves LDAP queries. I'm not sure why previous posts were talking about only measuring elapsed times for a subset of methods. Is it a technical issue for YourKit? It would be much better for users to have elapsed times recorded and displayed in a way very similar to cpu times with filters restricting methods at the users discretion.
So I would like to know, too, is this something that will be implemented in the near future?
Thanks.
So I would like to know, too, is this something that will be implemented in the near future?
Thanks.
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
-
- Posts: 1
- Joined: Fri Feb 17, 2006 6:41 pm
Sorry, but this tool is useless without elapsed time
Please implement this ASAP. This tool is near useless to me with only CPU time measured. I'm profiling a 3 tiered-application, not an algorithm. Elapsed time is very important. I suspect that many others are in my situation. Hard to believe that you missed this. Back to JProbe for now.
-
- Posts: 32
- Joined: Sat Sep 11, 2004 9:18 am
i second (or third or fourth this
I just replied in another thread about this "missing" time i also see when profiling the wicket framework.
I see 100ms time if i do System.currentMillis at the beginning and end of the HttpServlet.doGet() method. But yourkit only reports 48ms..
Then the quesiton remains where is that other 52ms gone to?
Maybe we can have a third time column in 'all' the views?
totaltime | cpu time | own time
?
I just replied in another thread about this "missing" time i also see when profiling the wicket framework.
I see 100ms time if i do System.currentMillis at the beginning and end of the HttpServlet.doGet() method. But yourkit only reports 48ms..
Then the quesiton remains where is that other 52ms gone to?
Maybe we can have a third time column in 'all' the views?
totaltime | cpu time | own time
?