Roundup #39: Performance Tricks, Orleans Dashboard, ASP.NET Tips, Six Little Lines of Fail

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Some performance tricks with .NET strings

I’ve created a pull request on the ASP.NET Core repository. At the beginning, the changes were just about changing the unsafe code (char*) for stackalloc to a safe version with Span<T>. So, it was a very small change. During the review, Oleksandr KolomiietsGünther Foidl, and David Fowler have suggested a few additional changes to improve the performance. Thank you very much for taking the time to review the PR! The comments were very interesting, so I’ve decided to explain them in a post.

Link: https://www.meziantou.net/2019/03/04/some-performance-tricks-with-net-strings

Microsoft Orleans   Dashboard

Quick update to a post I did a while back regarding Orleans Dashboard — additional reporting metrics for your cluster!

As a refresher, Orleans is a virtual actor model framework — a framework that can be used to build new, distributed “primitives”. These primitives’ work can be farmed out to a cluster of nodes as a means of getting “work” done faster than what would be possible if working constrained to a single piece of hardware.

Link: https://hackernoon.com/microsoft-orleans-dashboard-update-cpu-memory-stats-706daed82cf8

Tips and tricks for ASP.NET Core applications

This is a small collection of some tips and tricks which I keep repeating myself in every ASP.NET Core application. There’s nothing ground breaking in this list, but some general advice and minor tricks which I have picked up over the course of several real world applications.

Link: https://dusted.codes/advanced-tips-and-tricks-for-aspnet-core-applications

Six Little Lines of Fail – Jimmy Bogard

It seemed like an easy feature to implement, a checkout page to place an order. But this payment gateway has a simple API, so we added that. And this email service provider makes it possible to send an email with one line of code! Finally we can notify downstream systems via a message queue. The code looks simple, 6 little lines of distributed systems code.

But those lines hid a dark secret that we only found after launching. Customers complained they didn’t get their email. The back end system wasn’t getting updated from our messages. And by far the worst of all, customers complained they saw an error page but still got charged!

Clearly it wasn’t as easy as calling a few APIs and shipping, we actually need to worry about those other systems. In this session, we’ll look at taking our 6 lines of distributed systems fail, examining the inevitable failures that arise, and possible mitigating scenarios. We’ll also look at the coupling our code contains, and the ways we can address it. Finally, we’ll refactor towards a truly resilient checkout process that embraces, instead of ignoring, the fallacies of distributed computing.

Link: https://www.youtube.com/watch?v=LGG3IIHUG_w

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #37: .NET Core 1.x End of Life, gRPC, GraphQL, Benchmarking, Life Beyond Distributed Transactions

Here are the things that caught my eye this week in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

.NET Core 1.0 and 1.1 will reach End of Life on June 27, 2019

.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.

After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.

Link: https://devblogs.microsoft.com/dotnet/net-core-1-0-and-1-1-will-reach-end-of-life-on-june-27-2019/

gRPC for dotnet

https://twitter.com/davidfowl/status/109287056804556800

We plan to implement a fully-managed version of gRPC for .NET that will be built on top of ASP.NET Core HTTP/2 server. Here are some key features:

– API compatible with the existing gRPC C# implementation (your existing service implementations should work with minimal adjustments)
– Fully interoperable with other gRPC implementations (in other languages and other platforms)
– Good integration with the rest of ASP.NET Core ecosystem
– High-performance (we plan to utilize some of the cutting edge performance features from ASP.NET Core and in .NET plaform itself)
– We plan to provide a managed .NET Core client as well (possibly with limited feature set at first)

We are committed to delivering the managed server experience Microsoft.AspNetCore.Server functionalities in ASP.NET Core 3.0 timeframe. We will strive to also deliver the mananged client experience in 3.0.

Link: https://github.com/grpc/grpc-dotnet/

Adding a GraphQL Endpoint to Your ASP.NET Core API

Since GraphQL support is not provided within ASP.NET Core, you need a Nuget package. The one most commonly used is simply called GraphQL .NET. Which is available as open source thanks to Joe McBride and all contributors. When you install the package GraphQL.Server.Transports.AspNetCore you’ll get it as a dependency as well as everything you need to hook in into ASP.NET Core. Now that we’re here I also install GraphQL.Server.Ui.Playgroundwhich will enable me to test the API in the way I did when I showed you the products query.

Link: https://rolandguijt.com/adding-a-graphql-endpoint-to-your-api/

Introduction to Benchmarking C# Code with Benchmark .NET

Once you have narrowed your focus to particular areas of your code you start to get down to the method level. At this point, it’s useful to begin recording more accurate and specific benchmarks for your existing methods and code. This is where benchmarking should become your tool of choice. In C# we have a fantastic option in the form of Benchmark.NET. This library provides a vast array of benchmark tooling that can be used to measure and benchmark .NET Code. Benchmark .NET is now regularly used by the teams at Microsoft to measure their code.

Link: https://www.stevejgordon.co.uk/introduction-to-benchmarking-csharp-code-with-benchmark-dot-net

Life Beyond Distributed Transactions: An Apostate’s Implementation – Jimmy Bogard

Over a decade ago, Pat Helland authored his paper, “Life Beyond Distributed Transactions: An Apostate’s Opinion” describing a means to coordinate activities between entities in databases when a transaction encompassing those entities wasn’t feasible or possible. While the paper and subsequent talks provided great insight in the challenges of coordinating activities across entities in a single database, implementations were left as an exercise to the reader!

Fast forward to today, and now we have NoSQL databases, microservices, message queues and brokers, HTTP web services and more that don’t (and shouldn’t) support any kind of distributed transaction.

In this session, we’ll look at how to implement coordination between non-transactional resources using Pat’s paper as a guide, with examples in Azure Cosmos DB, Azure Service Bus, and Azure SQL Server. We’ll look at a real-world example where a codebase assumed everything would be transactional and always succeed, but production proved us wrong! Finally, we’ll look at advanced coordination workflows such as Sagas to achieve robust, scalable coordination across the enterprise.

Link: https://www.youtube.com/watch?v=IMvrg0bN9-o

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Practical ASP.NET Core SignalR: Azure SignalR Service

ASP.NET Core SignalR Scaling

In this section, I’m going to cover how to deal with scaling SignalR by using the Azure SignalR Service. This is a managed service that is an alternative to using the Redis backplane that I’ve described in the previous section.

You may want to use this option as it eliminates having to manage your own Redis instance as well as dealing with a load balancers configuration of sticky sessions (client affinity). Everything is all pre-configured for you, and is a fully managed service.

This blog post is apart of a course that is a complete step-by-setup guide on how to build real-time web applications using ASP.NET Core SignalR. By the end of this course, you’ll be able to build real-world, scalable, production applications using the tools and techniques provided in this course.

If you haven’t already, check out the prior sections of this course.

  1. Course Overview
  2. ASP.NET Core SignalR Overview
  3. Basics
  4. Server Hubs
  5. HubContext
  6. Authorization
  7. Scaling with Redis

SignalR Scaling

I’ve covered the basics of scaling in the previous section and how having a web farm poses problems when using SignalR.

If you haven’t already or are need an overview of a webfarm scenario with SignalR, check out that section which covers how to scale using Redis as a backplane.

Azure SignalR Service

First thing to do is add a new resource in Azure by and search for the SignalR Service.

As you are creating the new service, when selecting the pricing tier, note that the free tier does not support changing the unit count. Meaning you are limited to 20 connections and 20k messages/day. The standard tier gives you 1k connections per unit and 1M messages/day/unit and allows you to scale up to 100 units (depending on the region).

Once created, go to the Settings > Keys page where you will need to copy the Connection String

Configuration

First, you’ll need to reference the Microsoft.Azure.SignalR package in your csproj.

From here you simply need to change the ConfigureServices() to use AddAzureSignalR() and modify the Configure() to call UseAzureSignalR()

User Secrets

Now we need to place our Azure SignalR Service connection string in user secrets. To add to our secrets via the dotnet CLI:

dotnet user-secrets set Azure:SignalR:ConnectionString "Connection String Goes Here"   

If you’re unfamiliar with user secrets, check out my blog post on handling sensitive configuration data.

That’s it. You’ll now be using the Azure SignalR Service and be able to scale to 1000’s of connections.

Get The Course!

You’ve got several options:

  1. Check out my Practical ASP.NET Core SignalR playlist on my CodeOpinion YouTube channel.
  2. Access the full course now by enrolling for free on Teachable.
  3. Follow along with the blog post series here on CodeOpinion.com
    1. Course Overview
    2. ASP.NET Core SignalR Overview
    3. Basics
    4. Server Hubs
    5. HubContext
    6. Authorization
    7. Scaling with Redis
    8. Scaling with Azure SignalR Service

Source Code

All of the source code for this blog post and this course is available the Practical.AspNetCore.SignalR repo on GitHub.