+972 52-548-6969
Working on the Uber Profiler 3.0
One of the things that tend to get lost is the fact that Hibernating Rhinos is doing more than just working on RavenDB. The tagline we like to use is Easier Data, and the main goal we have is to provide users with better ways to access, monitor and manage their data.
We have started planning the next version of the Uber Profiler, that means Entity Framework Profiler, NHibernate Profiler, etc. Obviously, we’ll offer support for EF 7.0 and NHibernate 4.0, and we had gathered quite a big dataset for common errors when using an OR/M, which we intend to convert into useful guidance whenever our users run into such an issue.
But I realized that I was so busy working on RavenDB that I forgot to even mention the work we’ve been doing elsewhere. And I also wanted to solicit feedback about the kind of features you’ll want to see in the 3.0 version of the profilers.
Comments
I'd like to see the profiler have the ability to display all ado activity happening, not just items generated from the ORM. Currently we have to use EFProf for ORM info, and sqlprofiler for all non-EF stuff, and when using sql profiler we have to know which items are EF and should be ignored.
It would be nice to see all ado activity, with associated session info (web url, etc) and callstack. Then if you can detect that the ado activity was generated from an ORM, layer in more ORM related information (like session/db context stats).
Easier said than done?
Hi Patrick, If you'll use the ADO.Net Provider Factory, that would already happen to you.
Good to know. Just tried it and its almost what we want, but slightly off...
We tend to think about profiling from the perspective of a "request", not an objectcontext/session. A request could be a web request, a wcf operation call, an NServiceBus message being processed. Within a request, multiple object contexts & raw ado statements can be interchanged. It would be nice for the profiler to provide a way to group statements by request instead of (in addition to) context/session.
Web Request #1 [URL] EF Statement 1 [Context 1] EF Statement 2 [Context 1] ADO Statement EF Statement 3 [Context 2]
Today we call efprof APIs directly (like RenameObjectContextInProfiler) to improve developer experience. I think it would be fine to expose this capability by API only. It doesn't make a lot of sense for efprof to become aware of NServiceBus message handling boundaries.
Thoughts?
Patrick, I think that this is a good idea, I've added: http://issues.hibernatingrhinos.com/issue/UberProf-195
Will it ever be NHibernate 4? :) The nuget package is in alpha since October 2013.
Two more suggestions from the team:
Sometimes efprof is left open on a dev machine and when running our app for periods of time, efprof will consume memory until reaching OOM exception. Can the efprof data be streamed to disk or only maintain a FIFO threshold? Desired workflow is to be able to leave it open throughout the day, and periodically look at whats going on.
Our dev model is database-per-branch, and using git we create a lot of local branches. Having to keep adding/updating connectionstrings in the efprof UI to see results can be a pain. Is it possible to capture the connectionstring when intercepting the ado traffic? If so, could you associate a connectionstring with a "context" so we don't have to manually update connectionstrings for each branch?
I assume that you will drop Silverlight. Never upgraded as I really couldn't get along with the Silverlight version.
1) I'll check on that. 2) It is possible, we avoided doing that to reduce risk factors (leaking connection strings), but that seems to be something that people really want.
I would love to see a programmatic way to highlight certain statements within a session (eg. I might not be interested in 90% of what's happening with a session, but want to draw attention to a few statements in particular).
Also, in general, better documentation of the API for the profiler would be much appreciated as well!
...also..would you mind sharing what you guys have in mind for new features in the v3 generation of profilers?
Dan, Thanks, we create issues for that, and we'll have a proper release plan in a couple of weeks
Dan, Thanks, we create issues for that, and we'll have a proper release plan in a couple of weeks
We discovered another one today once we started using the ADO provider factory:
Parameter panel is not expandable; for long parameter name/values, its hard to use.
Parameter panel is not data-table friendly. When passing lots of structured data to a stored procedure, we will stuff the data into a DataTable, push the datatable into a sproc parameter, which matches a user-defined table type on the SQL server side. It would be nice to see the contents of the data table in the profiler.
Patrick, I'll contact you off the blog for more details.
Comment preview