ASP.NET Community Standup – July 21, 2015

Jeffrey Fritz

This is the next in a series of blog posts that will cover the topics discussed in the ASP.NET Community Standup.  The community standup is a short video-based discussion with some of the leaders of the ASP.NET development teams covering the accomplishments of the team on the new ASP.NET 5 framework over the previous week.  Within 30 minutes, Scott HanselmanDamian EdwardsJon Galloway and an occasional guest or two discuss new features and ask for feedback on important decisions being made by the ASP.NET development teams.

Each week the standup is hosted live on Google Hangouts and the team publishes the recorded video of their discussion to YouTube for later reference. The guys answer your questions LIVE and unfiltered.  This is your chance to ask about the why and what of ASP.NET!  Join them each Tuesday when a notice goes out on Scott Hanselman’s Twitter feed with the exact link to each week’s hangout.

The team has shared their scheduled roadmap of features and deliverables for ASP.NET 5 on GitHub.

This week’s meeting is below:

In this very special edition of ASP.NET Community Standup, Scott and Damian started with a quick tour of the “ASP.NET Smurf Lab” that is being used to help performance test the new ASP.NET web servers as they are being developed.   The specs for the machines in the lab are available online.

This is a real performance lab, and not some Hollywood conjured setup with refrigerator sized computers with lots of blinky lights.  The goal is to test out a series of different implementations to get some baseline performance numbers and compare them to the TestEmpowerment performance results  In Damian’s screen, he’s connecting with the SSL client PuTTY to one of the Ubuntu machines to generate network load with the open-source wrk tool.

More details and information about the progress of the benchmarks and performance tuning effort can be found in the ASP.NET Benchmarks repository on GitHub.

Damian showed us a test based on a pull request by Ben Adams using Windows 8 registered IO APIs (RIO), a layer on top of WinSock that help to improve throughput.  With a basic implementation that only scans for 2 carriage returns, which signals the end of the network Damian ran 450 connections with 32 threads on the client and 150 requests and delivered 7.7 million requests per second against this prototype service.   By comparison, a service called TcpEcho which is built on top of libuv is handling 2.4M requests/sec but saturates the CPU.

Damian pointed out that the team is being extremely careful about how logic will be inserted into the new service so that it does not stall processing and significantly impact performance.  This is why the team is using this test lab and these results are influencing the development of the kestrel web server.

Current Performance Results for various Web Frameworks

These benchmarks from TechEmpower are doing a standard set of work to respond to a request, and the prototype services Damian showed are not fully implemented to compete against these numbers.  Once the prototype ASP.NET HTTP service is fully implemented, we will have a proper number to compare against these benchmarks

Q & A

Question: Are there any gotchas with using VS 2015 RTM and the development branches of ASP.NET 5?

There is one issue with the naming of an object causing a problem with Visual Studio that will be fixed in next week’s release.

Question: With the roadmap now published, what is in 4.6 that will not be in ASP.NET 5?

The HTTP/2 push/promise API is not going to make it in ASP.NET 5, but is available in 4.6.  The other HTTP/2 features like header compression and request multiplexing are in the ASP.NET 5 featureset when used with Windows 10.

Question: Can you do an in-place upgrade of Visual Studio 2015 from RC to the RTM bits that were released this week?

Yes, the team went through this test prior to Visual Studio 2015 being released and they can confirm that it works great.

Question: Any guidance for SignalR usage in 5?

The roadmap dictates that SignalR and ASP.NET Webpages will not make the RTM release, but are scheduled to be available in Q3 2016.  There is a SignalR 3 beta5 package that supports some of the interfaces with the existing JavaScript clients for SignalR 2.  There are no guarantees that this beta will work through the end of the ASP.NET 5 development schedule.

Scott pointed out that Web Pages and SignalR are open source, and developers could contribute to those projects.  Damian furthered that SignalR could be updated by developers in the community with some Microsoft guidance but that Web Pages will change significantly and it may not be a good target for community contributions.


The team wrapped up this performance testing-focused discussion and demonstration with an open-ended question: do you enjoy these insights into the development and testing process?  Sound off in the comments below.  Next week the team will be meeting around 16:00 UTC on July 28th.

Feedback usabilla icon