xProfiler – A generic OR/M Profiler
With the release of NH Prof v1.0, I started to look if I can extend what I am doing for NHibernate for other OR/M in the .NET space. My initial spiking makes me optimistic, this is certainly possible. I’ll probably talk at length about the actual architectural implementation, but for now I want to concentrate on the actual high level requirements. I want to be able to support the following:
- Linq to SQL
- SubSonic
- LLBLGen
- Plug your own DAL
While none of them are going to provide me with the detailed information that I can get from NHibernate, it turns out that I can get a pretty good mileage from just pushing the basics along. The first spikes with Linq to SQL are promising (more about that will show up starting next week or the one after that), and I intend to allow you to:
- Show DataContext
- Show SQL Statements
- Show you the actual formatted SQL, including parameters
- Show you the stack trace of where that SQL was generated
- Generate alerts for bad practices such as SELECT N+1 or issuing too many queries
There are things that I can do with NHibernate that are simply not possible with other OR/Ms (something like tracking loaded entities per session, for example, or showing cached queries), but since most of those are actually capabilities that NHibernate has and the others do not, I think it is still great.
Currently the plan is to have a separate product for each OR/M, that means that buying NH Prof will not get you L2S Prof, but we will most likely have some uber license that will cover all of them.
You’ll notice that the Entity Framework isn’t listed in my initial targets list. That is for a very simple reason, plugging into EF seems to be about nine times harder than doing it with anything else. I would need to get a strong feedback that this is something that enough people are willing to pay for.
Comments
Sweet! As I tend towards SubSonic at the moment, that's good news. As it's Open Source, maybe Rob Conery can add some hooks that would make "SubProf" more awesome?
But in any case, you're really filling a hole here, as "Just use SQL Server Profiler to profile your ORM" is not the most satisfying situation and anything that makes the ORM Black Box more transparent without losing ORM functionality (aka. "If it's slow, just replace it with hand-written ADO.net") is great!
Any chance of a version that profiles ADO based code? Having something like NHProf for legacy code would be amazingly helpful.
Working with SQL Profiler after using NHProf feels like I'm going back to the stone age :)
Mike,
Yes, that is actually planned
Hi Ayende,
I am currently switching between NHibernate and Entity Framework and will continue to do so the coming years. I will end up buying NHProf eventually but I'd really love to see some Entity Framework support there.
Why is it harder to hook in to? I already built some simple query dumping / profiling methods for it and it wasn't that hard but maybe if you try to dig deeper into the framework it gets harder? Have you talked to the guys at the Entity Framework team about your plans? Maybe they'd be able to give you a few hints!
Further I am glad to see these plans of multiple ORM support. It is something that has been totally missing and it's going to be many developers best friend. Great work!
Mikael,
How are you doing this?
And as for the difficulty, there is going to be a post about it today
Hi Ayende,
Why would you like to support LINQ To SQL whilst it has been annouced that it is discontinued ? Were you talking about Entity Framework ?
Sounds very good to me - how about adding XPO from Developer Express to the list sometime?
Ayende,
I found the information I needed at http://www.scip.be/index.php?Page=ArticlesNET13 you might need to dig deeper into the framework though.
Anyway EF is probably not as big as L2SQL yet so I guess it can wait for a while.
Sean,
I would need to see how many people request it, and anyway it is something that I'll only consider after I finish the L2S one.
Neonp.
Put simply, L2S is a low hanging fruit, it is very easy to plug into it and it is a great PoC of the xProfiler.
And no, I am specifically NOT talking about EF for now
Mikael,
You are doing this manually, per each query?
Ayende,
Semi-manual. I turned the dumping to text file on/off in ".config" whenever I have had a problem with my queries and it became quite obvious that EF in it's current release form has some serious issues with joins ;)
When I am talking about manual, I am talking about having to touch every single query that you make
I see where you are going and in that case as darn manual as it gets.
That is more or less my point, for xProf, I can't expect you to do that.
I would also be interested in a product for EF.
Have you looked at wrapping providers?
http://code.msdn.microsoft.com/EFProviderWrappers
High level overview:
blogs.msdn.com/.../...le-on-msdn-code-gallery.aspx
Kim,
I saw that, yes. That is my comment about the nine times harder than anything else.
I think that you can plug into Entity Framework via reflection pretty easily. The Api would change every 2 years or so but that should not be a problem.
That's actually a great idea. I think you must mainly think about client-side profiling API allowing any ORM to notify it on a particular event.
It's easy to support them if API is open.
If you'll be quick, you have high chances to be the very first on this market ;)
I think it's better to start from providing an open API for NHProf. If so, most ORM vendors (+ community) will create its implementations for each ORM by their own, and you'll get significantly bigger market area with almost zero efforts.
Alex,
That is not quite as easy as it may seems.
Most of the work NH Prof is doing is done on the profiler side, not on the profiled side.
Things like extracting parameters, formatting SQL,defining alerts, etc.
Oren,
Just to throw ideas out there, DB4O doesn't have any profiler, and of course SQL Profiler does not work in that space. We could really use a DB4O profiler there. I'd pay money for it.
It would obviously require a big big big change in your code. But I thought I'd throw it out there as a wild idea.
Judah,
What do you want to see there?
Err... That seems even better.
On the other hand, I suspect there must be significant differences in alerts and their detection.
Alex,
Is IS better.
But it means that there is a lot of stuff there that I would need to handle. It is not just a matter of opening up some sort of an API.
Ah, yes - that's true. Well, that's the problem you must solve, if you're going to make it true ORM-independent ;)
E.g. alert detectors can be a part of profiler-side API. On the other hand, all info gathering stuff should be @ profiled side.
Frankly speaking, I studied NHProf just by screenshots you publish, so I don't know if it's even possible or not to implement this. I general, I feel it must be possible, but I don't know the details.
Anyway, if there will be such an API, we'd be glad to build a plugin for DO4.