PerfView:分析应用程序的性能,包括数据库调用 [英] PerfView: Analyzing Performance of App including Database Calls

查看:41
本文介绍了PerfView:分析应用程序的性能,包括数据库调用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在使用 PerfView 对我的 (C#) 应用程序进行性能分析.但通常这些应用程序使用大量的数据库调用.所以我问自己这样的问题:- 在存储库中花费了多少时间?-(等待 SQL 查询返回花费了多少时间?)-> 我不知道这是否可以用 PerfView 发现

I'm currently getting into PerfView for performance analysis for my (C#) apps. But typically those apps use a lot of database calls. So I asked myself questions like: - How much time is spent in Repositories? - (How much time is spent waiting for SQL Queries to return?) -> I don't know if this is even possible to discover with PerfView

但是从我的跟踪中我几乎没有得到任何有用的结果.在任何堆栈"视图中,它告诉我(当我在存储库上使用分组时)在我的存储库中花费了 1.5 秒(整个调用大约为 45 秒).而且我知道这不是真的,因为存储库调用了很多数据库.

But from my traces I get barely any useful results. In the "Any Stacks" View it tells me (when I use grouping on my Repository) that 1,5 seconds are spent in my Repsoitory (the whole call is about 45 seconds). And i know this is not really true, because the repositories calls the database A LOT.

是否只是在等待 SQL 查询完成时未捕获 CPU 指标,因为 CPU 在这段时间内无事可做,因此我的时间只包括存储库中的数据转换时间等?

Is it just that CPU metric is not captured when waiting for SQL Queries to complete because CPU has nothing to do in this period of time and therefore my times are just including data transformation times etc in the repository?

感谢您的帮助!

我错过的是打开线程时间选项来获取阻塞代码的时间(我想这是在数据库调用期间发生的事情).我现在得到了所有的堆栈,只是过滤掉了无趣的东西.但我似乎无处可去.

What i missed is turning on thread times option to get times of blocked code (which is what's happening during database calls i suppose). I got all the stacks now, just have filter out the uninteresting things. But i don't seem to get anywhere.

在使用线程时间"时对我来说特别有趣的是 BLOCKED_TIME.但有了它,我认为时代已经过去了.当您查看屏幕截图时,它告诉我 CPU_TIME 是 28,384.这是毫秒(afaik),但 BLOCKED_TIME 是 2,314,732,不能是毫秒.因此 CPU_TIME 的百分比非常低,只有 1.2%,但 70 秒中有 28 秒仍然很多.所以包容百分比时间在这里比较苹果和橙子.有人能解释一下吗?

What's especially interesting for me when using "Thread Time" is the BLOCKED_TIME. But with it the times are off i think. When you look at the screenshot, it tells me that CPU_TIME is 28,384. Which is milliseconds (afaik), but BLOCKED_TIME is 2,314,732, which can't be milliseconds. So percentage for CPU_TIME is very low with 1.2% but 28 out of 70 seconds are still a lot. So the Inclusive Percentage time is comparing apples and oranges here. Can somebody explain?

推荐答案

所以,我成功了.

我错过的(实际上 Vance Morrison 在他的视频教程中对此进行了解释)是:当使用 perfview 进行挂钟时间分析时,您会从所有等待"的线程中获得累积时间.BLOCKED_TIME".这意味着有 70 秒的时间,单独的终结器线程为此BLOCKED_TIME"增加了 70 秒,因为它坐在那里没有做任何事情(至少在我的情况下几乎没有任何事情).

What I missed (and Vance Morrison was explaining it in his video tutorial actually) is: When doing a wall clock time analysis with perfview, you get accumulated time from all the threads that have been "waiting around" in what is called "BLOCKED_TIME". Which means for a 70 seconds time, alone the finalizer thread adds 70 seconds to this "BLOCKED_TIME" because it was sitting there not doing anything (at least almost anything in my case).

因此,在进行挂钟时间分析时,重要的是过滤掉您感兴趣的内容.例如,搜索占用 CPU 时间最多的线程,然后将其包含在您的分析中,然后深入分析堆栈以查找昂贵的代码片段(也可能导致数据库或服务调用).只要您从方法的角度进行分析,您就会真正获得在此方法中花费的时间,并且累积的BLOCK_TIME"不在图片中.

So when doing wall clock time analysis it is important to filter out what you're interested in. For example search for the thread that was taking the most CPU-time and just include this one in your analysis and go further down the stack to find pieces of your code that are expensive (and also might lead to DB or Service Calls). As soon as you a analysis from the point of view of a method you are really getting the times that were spent in this method and the accumulated "BLOCK_TIME" is out of the picture.

我发现最有用的是在我自己的代码中搜索似乎很耗时"的方法,我切换到此方法的调用者视图.这从它被调用的位置以及在被调用者中查看是什么导致堆栈进一步消耗时间(存储库中的数据库调用或获取一些数据的服务调用)提供了一些启示.

What I found most useful is searching for methods in my own code that "seemed time consuming", i switched to the callers view for this method. Which shed some light from where it's called and in the callees view what is responsible for the consuming time further down the stack (a DB call in a repository or service calls for getting some data).

有点难以解释,但是一旦我真正理解了挂钟时间分析的基础知识,在某些时候这一切都是有意义的.

Little bit hard to explain, but as soon as i had understand really the basics of wall clock time analysis, it all made sense at some point.

我推荐这个视频教程:http://channel9.msdn.com/Series/PerfView-教程

再次,伟大且非常强大的工具!

Again, great and very powerful tool!

这篇关于PerfView:分析应用程序的性能,包括数据库调用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆