We’ve been getting some great feedback about our new Prefix tool. If you haven’t downloaded it yet, get it here. We’ve been using this tool as we build our Stackify product and want to share a few Prefix tips and tricks that you may or may not have picked up as you are using it. Watch the video for step-by-step detail. We’ve summarized the video content with helpful screenshots below.
The first thing to point out is the background shading. In the example in the video, you’ll see a red and orange colored background. These function as a timeline and make sure that anything that is slow, jumps out at you visually. Anything that over 50 milliseconds will show up as orange in color and then over two hundred seconds will show as red.
Another point of interest within Prefix is that it tracks how long it takes to receive the initial response and then how long it takes to actually download the entire response stream. Prefix will actually show you how long it takes to download the response stream.
Prefix does something similar for database queries. In our video example, you’ll see that the database query took 225 milliseconds, but about 122 of that was actually downloading the query result. What that means is about half the time SQL server was executing the query and started to send the results, but the rest of the time is how long it actually took with a reader to actually iterate through those results.
So sometimes you may see that it takes a couple of milliseconds to execute the query, but if it returns a lot of data and a lot of rows, it may take a while to download. Depending on other tools you’re using, it may show that it only took a couple seconds but the actual impact to your code and users from a real-world perspective can be much bigger.
Prefix will also show compilation time and time around entity framework. You’ll usually only see that on a first request, and if you reload the page, those things will go away. However, we want you to have some kind of idea of what that time is.
You probably already noticed that Prefix will capture the headers. It can capture incoming post data, it can also capture the response and the response headers and part of the response body. Right now, we limit that to only be a certain amount of characters so if it’s returning something larger, it won’t capture all of it. Prefix also captures the modules and gives you a friendly reminder of the modules that are being used you don’t need to use and can remove from your app. Prefix will show you if you have modules that are affecting performance.
Another thing you can do with Prefix is on the left side of the list, you can hold CTRL and click on a request. When you do that, you can open it in a new tab. That way you don’t have to worry about it scrolling by. Or open two or three of them to compare them in their own tabs.
On the left, when you click on the icons, Prefix will attempt to jump to that part of the profile trace to show what you clicked on. For a really small trace, there’s not a whole lot of scrolling to do, but for a larger request, it will try and jump down to that exact spot.
Another thing you’ll notice is Prefix automatically catches all exceptions. Because we’re profiling the .NET CLR, we are able to get every single exception that occurs even if it’s thrown and then you try catching it and just completely ignore the error, Prefix will catch those. Those types of errors can really cause a lot of performance issues, especially if you’re trying to parse a number and it fails all the time, it can cause a whole lot of performance problems. So Prefix will automatically catch all of those.
There are, however, some exceptions that get thrown by .NET, especially the first time a page is loaded and we worked hard to ignore certain exceptions so they’re not showing up all the time as noise.
Prefix supports logs from Log4net, Nlog and other logging libraries. You’ll notice that you can see JSON. So if you log an object, that object will automatically get serialized to JSON and show up in Prefix, so you can view it as JSON.
You’ve probably seen that you can expand the SQL queries and view the entire query. On the left side when you’re scrolling, you’ll notice a little caret symbol. If you ever scroll a long way down the page, you can click that caret and it will jump back to where you were.
Above the right side, in the requests in the app, you’ll see you can change the names. Changing the app name is helpful if you’re using several different apps, or testing something that calls a lot of web services. On the left you’ll see the app names in the list of requests. Changing the actual request name is a really powerful feature if you have something that conditionally does very different things. For example, an http handler or some kind of MVC action. We have dashboard widgets and every widget loads different database queries. We pass into that action and say what type of widget we want to load. It’s a lot more helpful to split out how we load each kind of widget, but because they all happen under the same action, they would normally get lumped together. By adding one line of code to your action you can specify a unique name and those show up as unique names. The same function works in our APM, so if you’re using Stackify APM and you make this change, it will also affect APM and how it reports.
Another thing to look for is how long Prefix reports reading a request and sending a response. If you have anything that hosts a whole lot of JSON data to an MVC action, Prefix will show how long it takes to deserialize the JSON that’s coming in and how long it takes to bind that to a class file. This is helpful to understand because perhaps you should look at using a different JSON serializer or deserializer.
On the bottom of your screen, you’ll see what kind of result it was – if it was a view or a JSON result. The one highlighted in the video took zero milliseconds. It does return some JSON, just not enough JSON that it takes a lot of time. However, if you look on the left to “gettoppeople,” it downloads quite a big list of things, and then returns it via JSON so you can see it takes 31 milliseconds, which isn’t terrible, but depending on what you’re doing, you may find some opportunities to improve performance by reducing the amount of data or changing serializers.
Another feature of the product list it how long it takes to render a view. This example shows 297 milliseconds to render a view. A big part of the problem is there’s a bunch of additional database queries happening because a lazy loading from entity framework because someone added an additional field. So every time, it’s got to go look up that field. Maybe you’ve had issues like that before with entity framework, NHibernate, or N+1 problems that you’ll see in different ORMs. Prefix will help you catch those.
We’ll share more of our tips and tricks for using Prefix here, or you can catch more on our YouTube channel.