This document has moved to: https://anthonysteele.github.io/AsyncBasicMistakes
I see a lot of code lately that makes some simple mistakes using the async ... await
construct.
- A Task is a promise of a value.
I see a lot of code lately that makes some simple mistakes using the async ... await
construct.
When we started coding on NuKeeper, things were different - there were automated update tools for other ecosystems,
but not for .NET, and I was working with a lot of services with a lot of dependencies.
Most (but not all) of these at my work were solutions in .NET full framework version 4.6.2
or the like.
I tried to find the .NET support on "Greenkeeper" before realising what the docs didn't even feel the need to spell out: this was for node.js
and NPM, only. So there was a gap and a need for .NET package automation.
Well, things changed. Most notably, Dependabot got .NET Core support,
and was acquired by GitHub, which was in turn acquired my Microsoft.
Automated package update management is a win for developers, so this is good for people working in .NET.
/* | |
* Example code for my blog post on function shims for NancyFx request handlers | |
* Blog post is here: http://anthonysteele.co.uk/more-patterns-for-web-services-in-nancyfx | |
*/ | |
using System; | |
using System.Collections.Generic; | |
using System.Threading.Tasks; | |
using Nancy; |
A microbenchmark on the new message context store in JustSaying. The last one, ReadWriteNewMessageContext
is probably the most realistic.
So we have an overhead of around 50 nanoseconds (5×10-5 ms). This is good. And I suggest that we don't bother with ways to opt in or out of this, just have it on all the time, regardless of if it is used by handlers or not.
// * Summary *
BenchmarkDotNet=v0.11.3, OS=Windows 10.0.17134.112 (1803/April2018Update/Redstone4)
Intel Core i7-8750H CPU 2.20GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=2.2.101
using System.Threading.Tasks; | |
using SqsMessage = Amazon.SQS.Model.Message; | |
namespace JustSaying.Messaging.MessageHandling | |
{ | |
public interface IHandlerAsync<in T> | |
{ | |
/// <summary> | |
/// Handle a message of a given type | |
/// </summary> |
rem nukeeper release script | |
rem in cmd: | |
cd C:\Code\NuKeeper\NuKeeper | |
del C:\Code\NuKeeper\NuKeeper\bin\Debug\*.nupkg | |
dotnet build | |
dotnet pack | |
cd C:\Code\NuKeeper\NuKeeper\bin\Debug | |
dir |
I have finally done a like-for-like benchmaerk on JustEat.Statsd
version 2.1 versus version 3.1
In order to get a consistent measurement, it has to be on the same machine under the same conditions.
dotnet run -c Release --framework netcoreapp2.0
BenchmarkDotNet=v0.11.0, OS=Windows 10.0.17134.167 (1803/April2018Update/Redstone4)
Intel Core i7-4712HQ CPU 2.30GHz (Max: 2.20GHz) (Haswell), 1 CPU, 8 logical and 4 physical cores
About optimisation and benchmarks; bottlenecks and what difference optimisation will make.
I heard that the ASP.NET core beta running on Kestrel Web server was capable of processing "over one million requests per second" though a simple benchmark Update: it's nearly 1.2 million now. The full benchmarks are at the bottom of this page
My thoughts were:
using System.Net; | |
namespace JustEat.StatsD.EndpointLookups | |
{ | |
public class EndpointData | |
{ | |
private readonly IPEndPoint _ipEndpoint; | |
private readonly string _hostName; | |
private readonly int _port; |
I got a lot out of Nathan Gloyn's talk at DDDEA on "Agile: I do not think it means what you think it means".
The slides of the talk are here.
The talk is about where it all went wrong - the mainstream adoption of agile, the brand-name of it, the descent into a cargo cult and the conflict between the principles and the rules.
One thing on slide #29 struck me as odd at the time: Don't be bound by "the rules".