Ayende @ Rahien

Gilad Shalit is back

Tue, 18 Oct 2011 10:00:00 GMT

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:

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.

What is next for the profilers?

Thu, 02 Jun 2011 09:00:00 GMT

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?

Uber Prof & NuGet

Fri, 01 Apr 2011 11:00:00 GMT

Fitzchak has all the details in our company blog.

NHibernate Profiler update: Client Profile & NHibernate 3.x updates

Sun, 13 Mar 2011 14:28:00 GMT

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.

New Profiler Feature: Avoid Writes from Multiple Sessions In The Same Request

Tue, 01 Mar 2011 12:26:00 GMT

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

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?

New Uber Prof Feature: Too Many Database Calls In The Same Request

Mon, 28 Feb 2011 12:15:00 GMT

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.

New Uber Prof Concept: Cross Session Alerts

Fri, 25 Feb 2011 10:05:00 GMT

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.

Uber Prof New Features: A better query plan

Sat, 15 Jan 2011 10:00:00 GMT

Originally posted at 1/7/2011

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

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.

Uber Prof New Features: Go To Session from alert

Fri, 14 Jan 2011 10:00:00 GMT

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:

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.

NH Prof New Feature: Alert on bad ‘like’ query

Thu, 09 Dec 2010 10:00:00 GMT

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:

Feature selection strategies for NH Prof

Tue, 07 Dec 2010 10:00:00 GMT

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:

Action	%	What it means
Selection	62.76%	Selecting a statement
Session-Statements	20.58%	Looking at a particular session statements
Recent-Statements	8.67%	The recent statements (default view)
Unique-Queries	2.73%	The unique queries report
Listening-Toggle	1.10%	Stop / Start listening to connections
Session-Usage	0.91%	Showing the session usage tab for a session
Session-Entities	0.54%	Looking at the loaded entities in a session
Query-Execute	0.50%	Show the results of a query
Connections-Edit	0.38%	Editing a connection string
Queries-By-Method	0.34%	The queries by method report
Queries-By-Url	0.27%	The queries by URL report
Overall-Usage	0.25%	The overall usage report
Show-Settings	0.23%	Show settings
Aggregate-Sessions	0.21%	Selecting more than 1 session
Reports-Queries-Expensive	0.16%	The expensive queries report
Session-Remove	0.13%	Remove a session
Queries-By-Isolation-Level	0.08%	The queries by isolation level report
File-Load	0.04%	Load a saved session
File-Save	0.03%	Save a session
Html-Export	0.02%	Exporting to HTML
Sessions-Diff	0.01%	Diffing two sessions
Sort-By-ShortSql	0.01%	Sort by SQL
Session-Rename	0.01%	Rename a session
Sort-By-Duration	0.01%	Sort by duration
Sort-By-RowCount	> 0.00%	Sort by row count
GoToSession	> 0.00%	Go from report to statement’s session
Sort-By-AvgDuration	> 0.00%	Sort by duration (in reports)
Production-Connect	> 0.00%	(Not publically available) Connect to production server
Sort-By-QueryCount	> 0.00%	Sort by query count (in reports)
Sort-By-Alerts	> 0.00%	Sort by alerts (for statements)
Sort-By-Count	> 0.00%	Sort by row count

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…

The most amazing demo ever

Wed, 01 Dec 2010 18:17:00 GMT

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.

What is Uber Prof’s competitive advantage?

Sat, 27 Nov 2010 10:00:00 GMT

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.

Profiler new features: Data binding alerts

Mon, 27 Sep 2010 10:00:00 GMT

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:

WPF detection:

WinForms detections:

Web applications:

Profiler new features, Sept Edition

Fri, 17 Sep 2010 11:00:00 GMT

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.

Estimates sucks, especially when I pay for them

Sun, 12 Sep 2010 10:00:00 GMT

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.)

The Profiler New Features: Starring & Renaming

Thu, 26 Aug 2010 08:13:00 GMT

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.

NH Prof & usage data

Thu, 19 Aug 2010 15:25:00 GMT

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.

NHProf new feature: Expensive queries report

Fri, 16 Jul 2010 09:09:51 GMT

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).

Profiler subscriptions are now open for all profilers

Mon, 26 Apr 2010 12:54:00 GMT

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

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.