We all know that bug happens. They are inevitable during development, and basically in every step-in software lifecycle.
The thing that makes a difference, is to catch them as early as you can. You do not want to be in a situation where production site is suffering huge performance issues with only handful of requests.
The earliest possible time could be when you are writing those new cool features. (Well, maybe good planning also eliminates a few. You can save hours of planning by coding for a week).
What is a Profiler?
Never make assumptions, so I’ll cover some basics here. Profiling basically means that your profiling tool (profiler) analyses your site when you run it on your development machine. While it runs, it shows you what your code is doing.
Simple example. Your code makes a call to the database. That call will be shown in the profiler with key information like: content of the query, time it takes to run and was it cached. If the query takes too much time, the profiler will flag a performance issue. If the query takes for example 0,5 seconds every time it runs on each and every site visitor… You have a bit of a problem, but you also have great opportunity to make huge performance improvement. Cache maybe?
Profiling AlloyDemoKit with Stackify Prefix
This content is suitable to any .NET project, but I will be taking a Episerver point of view on this. I’ll profile how well the Alloy reference solution performs, and if I could find any bugs from it. I’ll be using Stackify Prefix profiler.
I have started the website from Visual Studio and here you can see the view from the profiler. The reason for such long loading times (over 10 secs) is because of compiling. Next load would have been much faster.
What do we see here? The site started fine and no errors where visible on the website. However, we can see that there is some sort of an exception popping up from Prefix. Episerver is complaining about missing licence file. This isn’t a “real” error at development environment, but it demonstrates the power of the profiler to spot hidden exceptions that you might have otherwise overlooked.
Let’s look at another example. I’ll try to search the website using the site’s search box.
Internal Server Error, nice. That doesn’t tell me anything other than that something went wrong. I could open Episerver log files, but let’s have look at the profiler.
Bugs! The remote name could not be resolved: “yourfind.url.here”. Okay, I haven’t configured any Find indexes to the configuration. That was the problem!
What about those SQL queries?
In the example, I submitted an answer to a poll form. Everything went nicely on the frontend, but again some sort of file not found exception popped up in the profiler. We also have bunch of SQL queries happening here. These queries are Episerver’s own core functionality so we don’t have any optimisation possibilities there.
And finally, here we have cached page. No queries to the database, or to any other external resources.
Extremely fast loading time. This is what you might want to see in production.
I have only scratched the surface of profiling in this blogpost, so I would recommend that you give profiling a go on your current project. I’m quite sure that you will benefit it from one way or the other.
I personally use a profiler always as a “second screen” while developing and testing features. You can spot instantly hidden exceptions and bad performing code. And as a result, you will have more optimised site that has faster loading times and fewer bugs.
Everybody wins (except those bugs).
In my next post, I will write a bit more about measuring your code and site performance.