I don’t usually do posts about current events, but this one is huge.

To celebrate the event, you can use the following coupon code: SLT-45K2D4692G to get 19.41% discount (Gilad was captive for 1,941 days) for all our profilers:

• NHibernate Profiler
• Entity Framework Profiler
• Linq to SQL Profiler
• LLBLGen Profiler
• Hibernate Profiler

Hell, even our commercial support for NHibernate is participating.

Please note that any political comment to this post that I don’t agree with will be deleted.

We have been working on the profilers (NHibernate Profiler, Entity Framework Profiler, Linq to SQL Profiler, LLBLGen Profiler and Hibernate Profiler) for close to three years now. And we have been running always as 1.x, so we didn’t have a major release (although we have continual releases, we currently have close to 900 drops of the 1.x version).

The question now becomes, what is going to happen in the next version of the profiler?

• Production Profiling, the ability to setup your application so that you can connect to your production application and see what is going on right now.
• Error Analysis, the ability to provide you with additional insight and common solution to recurring problems.
• Global Query Analysis, the ability to take all of your queries, look at their query plans and show your potential issues.

Those are the big ones, we have a few others, and a surprise in store

What would you want to see in the next version of the profiler?

Fitzchak has all the details in our company blog.

We just finished a pretty major change to how the NHibernate Profiler interacts with NHibernate. That change was mostly driven out of the desire to fully support running under the client profile and to allow us to support the new logging infrastructure in NHibernate 3.x.

The good news, this is done , you can now use NH Prof from the client profile, and you don’t need to do anything to make it work for NHibernate 3.x.

The slightly bad news is that if you were relying on log4net conifguration to configure NH Prof, there is a breaking change that affects you. Basically, you need to update your configuration. You can find the full details on how to do this in the documentation.

Because I keep getting asked, this feature is available for the following profilers:

• NHibernate Profiler
• Entity Framework Profiler
• Linq to SQL Profiler
• LLBLGen Profiler
• Hibernate Profiler

This new feature detects a very interesting bad practice, write to the database from multiple session in the same web request.

For example, consider the following code:

public void SaveAccount(Account account)
{
    using(var session = sessionFactory.OpenSession())
    using(session.BeginTransaction())
    {
           session.SaveOrUpdate(account);
           session.Transaction.Commit();    
    }
}

public Account GetAccount(int id)
{
    using(var session = sessionFactory.OpenSession())
    {
        return session.Get<Account>(id);
    }
}

It is bad for several reasons, micro managing the session is just one of them, but the worst part is yet to come…

public void MakePayment(int fromAccount, int toAccount, decimal ammount)
{
    var from = Dao.GetAccount(fromAccount);
    var to = Dao.GetAccount(toAccount);
    from.Total -= amount;
    to.Total += amount;
    Dao.SaveAccount(from);
    Dao.SaveAccount(to);
}

Do you see the error here? There are actually several, let me count them:

• We are using 4 different connections to the database in a single method.
• We don’t have transactional safety!!!!

Think about it, if the server crashed between the fifth and sixth lines of this method, where would we be?

We would be in that wonderful land where money disappear into thin air and we stare at that lovely lawsuit folder and then jump from a high window to a stormy sea.

Or, of course, you could use the profiler, which will tell you that you are doing something which should be avoided:

Isn’t that better than swimming with the sharks?

Recently, we added a way to track alerts across all the sessions the request. This alert will detect whenever you are making too many database calls in the same request.

But wait, don’t we already have that?

Yes, we do, but that was limited to the scope of one session. there is a very large set of codebases where the usage of OR/Ms is… suboptimal (in other words, they could take the most advantage of the profiler abilities to detect issues and suggest solutions to them), but because of the way they are structured, they weren’t previously detected.

What is the difference between a session and a request?

Note: I am using NHibernate terms here, but naturally this feature is shared among all profiler:

• NHibernate Profiler
• Entity Framework Profiler
• Linq to SQL Profiler
• LLBLGen Profiler
• Hibernate Profiler

A session is the NHibernate session (or the data/object context in linq to sql / entity framework), and the request is the HTTP request or the WCF operation. If you had code such as the following:

public T GetEntity<T>(int id)
{
    using (var session = sessionFactory.OpenSession())
    {
         return session.Get<T>(id);
    }
}

This code is bad, it micro manages the session, it uses too many connections to the database, it … well, you get the point. The problem is that code that uses this code:

public IEnumerable<Friends> GetFriends(int[] friends)
{
   var results = new List<Friends>();
   foreach(var id in friends)
       results.Add(GetEnttiy<Friend>(id));

   return results;
}

The code above would look like the following in the profiler:

As you can see, each call is in a separate session, and previously, we wouldn’t have been able to detect that you have too many calls (because each call is a separate session).

Now, however, we will alert the user with a too many database calls in the same request alerts.

We have recently been doing some work on Uber Prof, mostly in the sense of a code review, and I wanted to demonstrate how easy it was to add a new feature. The problem is that we couldn’t really think of a nice feature to add that we didn’t already have.

Then we started thinking about features that aren’t there and that there wasn’t anything in Uber Prof to enable, and we reached the conclusion that one limitation we have right now is the inability to analyze your application’s behavior beyond the session’s level. But there is actually a whole set of bad practices that are there when you are using multiple sessions.

That led to the creation of a new concept the Cross Session Alert, unlike the alerts we had so far, those alerts looks at the data stream with a much broader scope, and they can analyze and detect issues that we previously couldn’t detect.

I am going to be posting extensively on some of the new features in just a bit, but in the meantime, why don’t you tell me what sort of features do you think this new concept is enabling.

And just a reminder, my architecture is based around Concepts & Features.

Originally posted at 1/7/2011

Because I keep getting asked, this feature is available for the following profilers:

• NHibernate Profiler
• Entity Framework Profiler
• Linq to SQL Profiler
• LLBLGen Profiler
• Hibernate Profiler

This feature is actually two separate ones. The first is the profiler detecting what is the most expensive part of the query plan and making it instantly visible. As you can see, in this fairly complex query, it is this select statement that is the hot spot.

Another interesting feature that only crops up whenever we are dealing with complex query plans is that the query plan can get big. And by that I mean really big. Too big for a single screen.

Therefore, we added zooming capabilities as well as the mini map that you see in the top right corner.

Originally posted at 1/7/2011

This is another oft requested feature that we just implemented. The new feature is available for the full suite of Uber Profilers:

• NHibernate Profiler
• Entity Framework Profiler
• Linq to SQL Profiler
• LLBLGen Profiler
• Hibernate Profiler

You can see the new feature below:

I think it is cute, and was surprisingly easy to do.

Uber Prof have recently passed the stage where it is mostly implemented using itself, so I just had to wire a few things together, and then I spent most of the time just making sure that things aligned correctly on the UI.

Originally posted at 12/3/2010

One of the things that are coming to NH Prof is more smarts at the analysis part. We now intend to create a lot more alerts and guidance. One of the new features that is already there as part of this strategy is detecting bad ‘like’ queries.

For example, let us take a look at this

This is generally not a good idea, because that sort of query cannot use an index, and requires the database to generate a table scan, which can be pretty slow.

Here is how it looks like from the query perspective:

And NH Prof (and all the other profilers) will now detect this and warn about this.

In fact, it will even detect queries like this:

Originally posted at 12/3/2010

I recently had a discussion on how I select features for NH Prof.  The simple answer is that I started with features that would appeal to me.  My dirty little secret is that the only reason NH Prof even exists is that I wanted it so much and no one else did it already.

But while that lasted for a good while, I eventually got to the point where NH Prof does everything that I need it to do. So, what next… ?

Feature selection is a complex topic, and it is usually performed in the dark, because you have to guess at what people are using. A while ago I setup NH Prof so I can get usage reports (they are fully anonymous, and were covered on this blog previously). Those usage reports come in very handily when I need to understand how people are using NH Prof. Think about it like a users study, but without the cost, and without the artificial environment.

Here are the (real) numbers for NH Prof:

There is nothing really earth shattering here, by far, people are using NH Prof as a tool to show them the SQL. Note how most of the other features are used much more rarely. This doesn’t mean that they are not valuable, but it does represent that a feature that isn’t immediately available on the “show me the SQL” usage path is going to be used very rarely.

There is another aspect for feature selection, will this feature increase my software sales?

Some features are Must Have, your users won’t buy the product without them. Some features are Nice To Have, but have no impact on the sale/no sale. Some features are very effective in driving sales.

In general, there is a balancing act between how complex a feature is, how often people will use it and how useful would it be in marketing.

I learned quickly that having better analysis (alerts) is a good competitive advantage, which is why I optimized the hell out of this development process. In contrast to that, things like reports are much less interesting, because once you got the Must Have ones, adding more doesn’t seem to be an effective way of going about things.

And then, of course, there are the features whose absence annoys me…

I was giving a talk yesterday at the Melbourne ALT.Net group, the topic of which was How Ayende’s Build Software. This isn’t the first time that I give this talk, and I thought that talking in the abstracts is only useful so much.

So I decided to demonstrate, live, how I get stuff done as quickly as I am. One of the most influential stories that I ever read was The Man Who Was Too Lazy to Fail - Robert A. Heinlein. He does a much better job in explain the reasoning, but essentially, it comes down to finding anything that you do more than once, and removing all friction from it.

In the talk, I decided to demonstrate, live, how this is done. I asked people to give me an idea about a new feature for NH Prof. After some back and forth, we settled on warning when you are issuing a query using a like that will force the database to use a table scan.  I then proceed to implement the scenario showing what I wanted:

public class EndsWith : INHibernateScenario
{
    public void Execute(ISessionFactory factory)
    {
        using(var s = factory.OpenSession())
        {
            s.CreateCriteria<Blog>()
                .Add(Restrictions.Like("Title", "%ayende"))
                .List();
        }
    }
}

Implemented the feature itself, and tried it out live. This showed off some aspects about the actual development, the ability to execute just the right piece of the code that I want by offering the ability to execute individual scenarios easily.

We even did some debugging because it didn’t work the first time. Then I wrote the test for it:

public class WillDetectQueriesUsingEndsWith : IntegrationTestBase
{
    [Fact]
    public void WillIssueWarning()
    {
        ExecuteScenarioInDifferentAppDomain<EndsWith>();

        var statementModel = model.RecentStatements.Statements.First();

        Assert.True(
            statementModel.Alerts.Any(x=>x.HelpTopic == AlertInformation.EndsWithWillForceTableScan.HelpTopic)
            );
    }
    
}

So far, so good, I have been doing stuff like that for a while now, live.

But it is the next step that I think shocked most people, because I then committed the changes, and let the CI process takes care of things.  By the time that I showed the people in the room that the new build is now publically available, it has already been download.

Now, just to give you some idea, that wasn’t the point of this talk. I did a whole talk on different topic, and the whole process from “I need an idea” to “users are the newly deployed feature” took something in the order of 15 minutes, and that includes debugging to fix a problem.

Originally posted at 11/25/2010

In a recent post, I discussed the notion of competitive advantage and how you should play around them. In this post, I am going to focus on Uber Prof. Just to clarify, when I am talking about Uber Prof, I am talking about NHibernate Profiler, Entity Framework Profiler, Linq to SQL Profiler, Hibernate Profiler and LLBLGen Profiler. Uber Prof is just a handle for me to use to talk about each of those.

So, what is the major competitive advantage that I see in the Uber Prof line of products?

Put very simply, they focus very heavily on the developer’s point of view.

Other profilers will give you the SQL that is being executed, but Uber Prof will show you the SQL and:

• Format that SQL in a way that make it easy to read.
• Group the SQL statements into sessions. Which let the developer look at what is going on in the natural boundary.
• Associate each query with the exact line of code that executed it.
• Provide the developer with guidance about improving their code.

There are other stuff, of course, but those are the core features that make Uber Prof into what it is.

The following features apply to NHProf, EFProf, L2SProf.

In general, it is strong discouraged to data bind directly to an IQueryable. Mostly, that is because data binding may actually iterate over the IQueryable several times, resulting in multiple queries being generated from something that can be done purely in memory. Worse, it is actually pretty common for data binding to result in lazy loading, and lazy loading from data binding almost always result in SELECT N+1. The profiler can now detect and warn you about such mistakes preemptively. More than that, the profiler can also now detect queries that are being generated from the views in an ASP.Net MVC application, another bad practice that I don’t like.

You can find more information about each warnings here:

• Data Binding & Queries Shouldn’t Mix
• Don’t Query From The View

WPF detection:

WinForms detections:

Web applications:

The following features apply to NHProf, EFProf, HProf, L2SProf.

The first feature is something that was frequently requested, but we kept deferring. Not because it was hard, but because it was tedious and we had cooler features to implement: Sorting.

Yep. Plain old sorting for all the grids in the application.

Not an exciting feature, I’ll admit, but an important one.

The feature that gets me exciting is the Go To Session. Let us take the Expensive Queries report as a great example for this feature:

As you can see, we have a very expensive query. Let us ignore the reason it is expensive, and assume that we aren’t sure about that.

The problem with the reports feature in the profiler is that while it exposes a lot of information (expensive queries, most common queries, etc), it also lose the context of where this query is running. That is why you can, in any of the reports, right click on a statement and go directly to the session where it originated from:

We bring the context back to the intelligence that we provide.

What happen if we have a statement that appear in several sessions?

You can select each session that this statement appears in, getting back the context of the statement and finding out a lot more about it.

I am very happy about this feature, because I think that it closes a circle with regards to the reports. The reports allows you to pull out a lot of data across you entire application, and the Go To Session feature allows you to connect the interesting pieces of the data back to originating session, giving you where and why this statement was issued.

I recently got an estimate for a feature that I wanted to add to NH Prof. It was for two separate features, actually, but they were closely related.

That estimate was for 32 hours.

And it caused me a great deal of indigestion. The problem was, quite simply, that even granting that there is the usual padding of estimates (which I expect), that timing estimate was off, way off. I knew what would be required for this feature, and it shouldn’t be anywhere near complicated enough to require 4 days of full time work. In fact, I estimated that it would take me a maximum of 6 hours and a probable of 3 hours to get it done.

Now, to be fair, I know the codebase (well, actually that isn’t true, a lot of the code for NH Prof was written by Rob & Christopher, and after a few days of working with them, I stopped looking at the code, there wasn’t any need to do so). And I am well aware that most people consider me to be an above average developer.

I wouldn’t have batted an eye for an estimate of 8 – 14 hours, probably. Part of the reason that I have other people working on the code base is that even though I can do certain things faster, I can only do so many things, after all.

But a time estimate that was 5 – 10 times as large as what I estimated was too annoying. I decided that this feature I am going to do on my own. And I decided that I wanted to do this on the clock.

The result is here:

This is actually total time over three separate sittings, but the timing is close enough to what I though it would be.

This includes everything, implementing the feature, unit testing it, wiring it up in the UI, etc.

The only thing remaining is to add the UI works for the other profilers (Entity Framework, Linq to SQL, Hibernate and the upcoming LLBLGen Profiler) . Doing this now…

And we are done.

I have more features that I want to implement, but in general, if I pushed those changes out, they would be a new release that customers can use immediately.

Nitpicker corner: No, I am not being ripped off. And no, the people making the estimates aren't incompetent. To be perfectly honest, looking at the work that they did do and the time marked against it, they are good, and they deliver in a reasonable time frame. What I think is going on is that their estimates are highly conservative, because they don't want to get into a bind with "oh, we run into a problem with XYZ and overrun the time for the feature by 150%".

That also lead to a different problem, when you pay by the hour, you really want to have estimates that are more or less reasonably tied to your payments. But estimating with hours has too much granularity to be really effective (a single bug can easily consume hours, totally throwing off estimation, and it doesn't even have to be a complex one.)

An interesting thing happened recently, when I started to build the profiler, a lot of the features were what I call Core Features. Those were the things that without which, we wouldn’t have a product. Things like detecting SQL, merging it into sessions, providing reports, etc. What I find myself doing recently with the profiler is not so much building Core Features, but building UX features. In other words, now that we have this in place, let us see how we can make better use of this.

Case in point, the new features that were just released in build 713. They aren’t big, but they are there to improve how people are commonly using the products.

Renaming a session:

This is primarily useful if you are in a long profiling session and you want to mark a specific session with some notation:

Small feature, and individually not very useful. But you might have noticed that the sessions are marked with stars around them. They weren’t there is previous builds, so what are they?

They are a way to tell the profiler that you really like those sessions :-)

More to the point, such sessions will not be removed when you clear the current state. That lets you keep around the previous state of the application as a base line while you work to improve it. Beside, it makes it much easier to locate them visually.

And finally, as a quicker way to do that, you can just ask the profiler to clear all but the selected features.

Not big features, but nice ones, I think.

There seems to be some suspicion about the usage data from NH Prof that I published recently.

I would like to apologize for responding late to the comments, I know that there are some people who believe that I have installed a 3G chip directly to my head, but I actually was busy in the real world and didn’t look at my email until recently. The blog runs on auto pilot just so I’ll be able to do that, but sometimes it does give the wrong impression.

So, what does NH Prof “phone home” about?

Well, the data is actually divided into two distinct pieces. Most of the data (numbers, usages, geographic location, etc) actually comes from looking at the server logs for the update check.

Another piece of data that the profiler reports is feature usage. There are about 20 – 30 individual features that are being tracked for usage. What does it means, tracking a feature?

Well, here are three examples that shows what gets reported:

There is no way to correlate this data to an individual user, nor is there a way to track the behavior of a single user.

I use this data mainly in order to see what features are being used most often (therefore deserving the most attention, optimizations, etc).

Those are mentioned in the product documentation.

To summarize:

• I am not stealing your connection strings.
• I don’t gather any personally identifying data (and I am at somewhat at a loss to understand what I would do with it even if I did).
• There is never any data about what you are profiling being sent anywhere.

I hope this clear things out.

It has been a while since we had a new major feature for the profiler, but here it is:

The expensive queries report will look at all your queries and surface the most expensive ones across all the sessions. This can give you a good indication on where you need to optimize things.

Naturally, this feature is available across all the profiler profiles (NHibernate Profiler, Entity Framework Profiler, Linq to SQL Profiler and Hibernate Profiler).

After trying it out on NH Prof, profiler subscriptions are now opened for all the profilers.

• Linq To SQL Profiler
• Entity Framework Profiler
• Hibernate Profiler

A profiler subscription allows you to pay a small monthly free (~16$) and get the full profiler capabilities along with the assurance of no upgrade cost when the next major version comes out.

In addition to the monthly subscription, I got requests for a yearly subscription. I am not sure that I quite follow the logic, but I am not going to make it harder for people to give me money, so that is available as well for all profilers.

One of the repeated requests for the profiler was to provide some alternative to the full price. After due consideration, I chose to implement an additional licensing model for the profiler, a subscription based one.

The current licensing model is still available and will not change!

What does this mean? Using the subscription model, you pay a monthly fee, and you can keep using the profiler as long as you pay.

The monthly fee is 12 Euro / 16$ US.

Why 12 Euro / 16$? It isn’t a “normal” price point.

When looking at the pricing model for subscriptions, I wanted to choose something low enough that most people wouldn’t mind paying. I choose this particular price point because this is how much a business lunch cost at a nearby restaurant. I believe that it should be low enough for everyone in the target audience.

The terms are simple:

• Payment is made month to month (that is, you get charged each month for the profiler).
• You can cancel the subscription at any point in time, and your copy of the profiler will expire when the time it due.
• Upgrading between version will happen automatically. That is, if you are subscribed to version 1.x, you’ll get 2.x automatically.

Subscriptions are currently offered for NH Prof only, but we will expand that to the other profilers if this prove successful.

You can buy a subscription here.

As part of the performance work I am doing for Uber Prof, I fixed a couple of issues related to profiling very busy applications.

Here is the result on processing a 4GB input file.

I can’t say that the profiler is happy about it, but it works.

Last week I gave a talk about the things I learned from building NH Prof.

Skills Matter had recorded the session and made it available.

Looking forward for your comments, but I should disclaimer that this was after a full day of teaching and on 50 min of sleep in the last 48 hours

This is Josh’s feature, since we wrote most of the code for it together. Basically, it recognize a very common performance problem, queries that uses too many joins, such as this one:

Which would result in the following warning:

Queries with too many joins might be a performance problem. Each join requires the database to perform additional work, and the complexity and cost of the query grows rapidly with each additional join. While relational database are optimized for handling joins, it is often more efficient to perform several separate queries instead of a single query with several joins in it.

For OLTP systems, you should consider simplifying your queries or simplifying the data model. While I do not recommend avoiding joins completely, I strong discourage queries with large numbers of joins. Another issue to pay attention to is possible Cartesian products in queries contains joins, it is very easy to create such a thing and not notice it during development.

This isn’t a new feature, because you can’t use it right now, but it is a really nice feature that we are working on, and I couldn’t resist showing it off hot “off the press”, so to speak.

Given the following query:

SELECT this_.id             AS id7_1_,
       this_.title          AS title7_1_,
       this_.subtitle       AS subtitle7_1_,
       this_.allowscomments AS allowsco4_7_1_,
       this_.createdat      AS createdat7_1_,
       posts2_.blogid       AS blogid3_,
       posts2_.id           AS id3_,
       posts2_.id           AS id0_0_,
       posts2_.title        AS title0_0_,
       posts2_.TEXT         AS text0_0_,
       posts2_.postedat     AS postedat0_0_,
       posts2_.blogid       AS blogid0_0_,
       posts2_.userid       AS userid0_0_
FROM   blogs this_
       LEFT OUTER JOIN posts posts2_
         ON this_.id = posts2_.blogid
WHERE  this_.id = 1 /* @p0 */

SELECT this_.id            AS id0_1_,
       this_.title         AS title0_1_,
       this_.TEXT          AS text0_1_,
       this_.postedat      AS postedat0_1_,
       this_.blogid        AS blogid0_1_,
       this_.userid        AS userid0_1_,
       comments2_.postid   AS postid3_,
       comments2_.id       AS id3_,
       comments2_.id       AS id2_0_,
       comments2_.name     AS name2_0_,
       comments2_.email    AS email2_0_,
       comments2_.homepage AS homepage2_0_,
       comments2_.ip       AS ip2_0_,
       comments2_.TEXT     AS text2_0_,
       comments2_.postid   AS postid2_0_
FROM   posts this_
       LEFT OUTER JOIN comments comments2_
         ON this_.id = comments2_.postid
WHERE  this_.blogid = 1 /* @p1 */

The profiler can show you the query plan using this UI:

And here is how the same query looks like using the query plan feature in Management Studio:

So, why implement it?

• This isn’t limited to SQL Server, the profiler can display query plans for: SQL Server, Oracle, PostgreSQL and MySQL
• This let you keep yourself in the flow, just hit a button to see the query plan, instead of copying the SQL, opening SSMS, displaying the query plan, etc.

Don’t discount the last one, making it easy is one of the core values of the profiler.

The idea is that if you make it easy enough, the barriers for using it goes away. If you can instantly see the query plan for a query, you are far more likely to look at it than if it takes 30 seconds to get that. At that point, you would only do it when you already have a performance problem.