http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Sam @Marc: MVC Mini Profiler is a great tool! Thank you very much you developing it and giving away for free to us. http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment15http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment15Fri, 02 Sep 2011 13:21:16 GMTAyende, Yep use it all the time, particularly to ignore cached quereis :) The reason I use the Ignore / Resume calls is that in our solution we have to interact with a couple of DLL's that were written by another team and I have no control over. I don't really care about profiling the calls made from those DLL's and it's a little tricky to filter them out via the UI so I just ignore them. I guess I was just trying to emphasise the point that you take an "opt out" approach and they take an "opt in" approach. If you install the NuGet package for the mini profiler and put the one liner for the includes in your master page, you have essentially enabled the profiler and it basically logs nothing. You then build up what makes sense for you to profile and in fact, you can often do it in very unobtrusive ways using things like ActionFilters, IoC and hooking into the ViewEngine pipelines makes this all pretty easy and straight forward. Basically with around 20 lines of code, I can get timings on how long it takes me to render / locate views, execute action methods and it gives me a birdseye view of what's happening in my code without actually having to change the *actual* code base. This code all sits on the outside and it really is minimal.http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment14http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment14Wed, 31 Aug 2011 08:44:28 GMTNick, You generally can't do that without a lot of complex infrastructure (proxying, weaving, etc)http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment13http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment13Wed, 31 Aug 2011 08:29:34 GMTName == Nick I was thinking you can use fluent configuration to specify which methods you want to profile via the wonder of lambdas. Behind the scenes this would use reflection to hook into a method call - just before and just after - to measure the time it takes. I don't know if you can definitely do this, it was more of a question. http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment12http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment12Wed, 31 Aug 2011 08:18:58 GMTPhil, Are you aware that NH Prof contains a sophisticated filtering engine?http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment11http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment11Wed, 31 Aug 2011 06:36:37 GMTName, Huh? What do you mean?http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment10http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment10Wed, 31 Aug 2011 06:36:16 GMTThe MP is a great tool, but you need to have a think about how you're going to use it. One thing I think Sam and the guys could do better is explain that the benefit of the Step calls is it gives you the ability to have very precise fine grained control over what is profiled. A lot of people seem to miss the point with the MVC mini profiler and the Step calls. They're nothing more than the gateway into the profiler and how you use them is up to you. If you want to go pouring them wholesale throughout your code then that's up to you but obviously that's going to cause you problems. If you are going to sprinkle them through your code after careful consideration as to what is going to provide the best benefit to you, then that is probably closer to the approach these guys were trying to encourage. The point is, that the control is thrown into the developers court. Contrasting this with NHProf Ayende, the approach you take is to profile everything (which is fine) but if you want to ignore specific queries, you can use this method outlined here: http://nhprof.com/Learn/Usage/IgnoreResumeProfiling I use this feature a lot because by default, I have a lot of queries that I know I can safely ignore (i.e. cached queries etc) that end up just being noise in the profiler. The only difference I see in this approach and the MVC mini profiler is that NHProf is opt out and MVC mini profiler is opt int. I think both tools are great and I use them both, but for different purposes and certainly wouldn't want to go back to writing apps without them.http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment9http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment9Wed, 31 Aug 2011 04:03:31 GMTWhat about fluent configurations with Lamda expressions and reflection wizadry?http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment8http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment8Tue, 30 Aug 2011 18:43:43 GMTWe have a number of scenarios where we query data from places other than a DB, sure. And knowing how they perform is key. Not everything is the DB. For example, some very high volume queries (that aren't a standard flat cache hit scenario) can be served from in-memory structures, but we still need to know how that performs. Ultimately, *anything* can become a performance issue if you don't keep a reasonable eye on it. Of course, a simpler answer here would be: Q: Do you have significant non db costs somewhere? A: If we didn't profile, how could we answer that? You could say "subtract DB time from total time", but that isn't necessarily enough - some performance issues can exist in the glue between layers. For example, we found significant chunks of time being swallowed by the materializer we were using. Replacing that with "dapper" solved that. Performance is hugely important to us, and having suitable tools to analyze and fix (with evidence) any performance goes a long, long way beyond just the database.http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment7http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment7Fri, 22 Jul 2011 09:33:55 GMTSam, That is actually interesting, why do you need that? Do you have significant non db costs somewhere?http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment6http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment6Thu, 21 Jul 2011 02:34:23 GMTTotally agree we should wire up time in view vs time in action automatically. Ideally we should hook in somehow and get time in each partial as well. However that only gets us a certain way, often we need to time subsections inside controllers and such to get better visibility of orm overhead and non db work. http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment5http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment5Thu, 21 Jul 2011 02:31:35 GMTSam, The problem is that you can get pretty high numbers for a lot of things once you start getting into the hang of it. And 0.1 ms starts getting big pretty fast, once you add things up. Your scenario doesn't need it, but mine did, I have it enabled for all users. I would have zero problems if you did that via an ActionFilter, for example. I just really don't like having it inside everything. +1 on logging, it is _important_, but the way you handle it in the sample code? I would call it an anti pattern.http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment4http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment4Thu, 21 Jul 2011 02:18:58 GMTI dunno, the stack trace trick is kind of fancy and allows you for pretty awesome optimization, however there is no arguing it is risky and could just break out of the blue. Considering that we are talking 0.1ms for the typical case this *only* introduces a 2ms slowdown for a page with say 20 queries which is all you should probably be running if you want to scale. Also we only instrument for particular users (admins) and for sampling purposes, so impact is minimal. Regarding the code blocks, that is a subject for a big blog post. You can have a slightly cleaner pattern using attributes and PostSharp style interception - if you are feeling particularly crazy you can attach to the running process once in a while and gather a list of interesting stack traces that seem to be hit frequently and then recompile with the instrumentation in place or jack it in with ICorProfiler. However the fancy means the solution becomes way more brittle. There is something to be said for having logging in your application, I would argue the the profiling blocks are just another form of logging. http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment3http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment3Thu, 21 Jul 2011 02:08:53 GMTMarc, As I understand it, this is only enable for specific cases, not for every page request, which is the case with RavenDB Profiler. As for not having to use the invasive code, I agree, but as it is the very first example... it seems that it is meant to be that. I didn't need a generic profiler for RavenDB, all I needed was something to handle RavenDB scenarios.http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment2http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment2Thu, 21 Jul 2011 02:02:09 GMTI think you missed a few points about MVC Mini Profiler; first: you don't *have* to add that "invasive" code; if you just want a trace of the SQL code, that will all happen automatically with the connection tracer - no code changes beyond connection setup. This will include stacktrace etc. That code is to help you profile *other* code - not all of a major system is TSQL. Indeed, at SO we cache like damnation. second: you state one of your goals is to run it *in production*. Same here; we run it on the entire network of Stack Exchange sites (including Stack Overflow etc). 24x7. All the time. In production. The purpose is not different.http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment1http://ayende.com/66561/why-i-don-t-like-the-mvc-mini-profiler-codebase#comment1Thu, 21 Jul 2011 01:06:28 GMT