In the previous post, I wrote about profiling your Episerver site and how important it is to spot bugs and performance issues early on. Now it’s time to create some traffic in your development environment and analyse how well your site performs under load.
We will be using a free open source tool called Netling by Tore Lervik. It is as simple as it gets to measure application performance on your machine. Site what we are using is of course AlloyDemoKit running on local (virtual) machine.
Netling comes with a simple user interface and a command line tool. We’ll be using the command line since that it more developerish? In the image below you see the basic commands which are pretty self-explanatory. Key points are thread count, how long the test should run (duration) and website address where the traffic should go.
Let’s create a simple test. We are running the Alloy site in IIS Express via Visual Studio and we would like to create some traffic to the front page. We also want to run the Stackify Profiler in the background so we will be able to see what kind of requests are happening during the load test. (Check my previous post about profiling with Stackify).
Let’s run a command: “netling -t 4 -d 10 -a http://localhost:51481/en/” in the command line. So, four threads, with 10 second duration to a localhost web address.
Not bad performance. Median load time for all the 172 requests were 0,2 seconds. In the profiler, we can see all the individual requests that happened during the load test.
The thing that pops out, is that there is a call to the database in every request. What going on here?
It seems that the AlloyDemoKit uses the FindPagesWithCriteria-method which isn’t cached by default. So, one request makes a huge single impact to the overall performance. Can we improve this?
With little investigating the culprit seems to be the PageListBlockController, and there we can find the FindPages-method. Following it, will lead us eventually to the ContentLocator.cs where we can find the FindPagesByPageTypeRecursively-method and there the FindPagesWithCriteria.
So, let’s try a simple controller level 10 seconds OutputCache (by no means this probably isn’t the best course of action) and run the load test again.
Nice! We got some significant performance improvement here. Let’s look again the profiler.
No more calls to the database and the single request time has improved significantly. Job well done!
For a more comprehensive performance measurement tool have a look at JMeter. There is also a nice blogpost by Solita and how they are using JMeter in Episerver development. http://dev.solita.fi/episerver/2016/01/21/measuring-episerver-site-performance.html