Rest vs gRPC – performance benchmark in .Net Core 3.1

Hey Guys!

The last days in Poland are cold & cloudy. This weather is a great motivator to reflect on… Communication protocols :-)!

This article presents….

• gRPC CodeFirst approach,
• The performance benchmark for gRPC vs REST communication in .Net core 3.1,
• How many does cost to open gRPC channel & why is worth to scope it like HttpClient,
• Note: All tests were started on my local PC, so all network traffic was occured in localhost & self signed ssl certs.

gRPC CodeFirst approach.

Firstly, I want to show You a little different way of creating gRPC web services than Microsoft official docs. Maybe a long time ago You heard something about gRPC, something about the requirement to have a .proto contract files for generating base, service classes. Maybe, when You look at this, You were scared (I did). What if I tell You, there is a different, unofficial way of creating gRPC services? Does this different approach have this same performance, no .proto files & shorter way of implementation based on C# models, interfaces & attributes? This is protobuf-net.Grpc library created by Marc Gravell. From now, You can forget about ContractFirst and focus on creating contracts by .net coding! (btw. it’s also possible to create .proto files from it :-))!

    [ServiceContract]
    public interface IUserGrpcService
    {
        ValueTask<UserDto> ActivateAsync(ActivateUserCommand command, CallContext context = default);
        ValueTask<CreatedUserDto> CreateUserAsync(CreateUserCommand command, CallContext context = default);
        ValueTask<AuditedUserDto> LoginAsync(LoginCommand command, CallContext context = default);
        ValueTask<ResetPasswordDto> ResetPasswordAsync(ResetPasswordCommand command, CallContext context = default);
        ValueTask<UserDto> SetNewPasswordAsync(SetNewPasswordCommand command, CallContext context = default);
    }

    [ProtoContract]
    public class UserDto
    {
        [ProtoMember(1)]
        public long Id { get; set; }
        [ProtoMember(2, DataFormat = DataFormat.Default)]
        public DateTime CreatedAt { get; set; }
        [ProtoMember(3)]
        public string Email { get; set; }
    }

    // Server
    public class UsersGrpcService : IUserGrpcService
    {
        private readonly IMediator _mediator;

        public UsersGrpcService(IMediator mediator)
        {
            _mediator = mediator;
        }

        public async ValueTask<UserDto> ActivateAsync(ActivateUserCommand command, CallContext context = default)
            => await _mediator.Send(command, context.CancellationToken);

        public async ValueTask<CreatedUserDto> CreateUserAsync(CreateUserCommand command, CallContext context = default)
            => await _mediator.Send(command, context.CancellationToken);
        
        public async ValueTask<AuditedUserDto> LoginAsync(LoginCommand command, CallContext context = default)
            => await _mediator.Send(command, context.CancellationToken);

        public async ValueTask<ResetPasswordDto> ResetPasswordAsync(ResetPasswordCommand command, CallContext context = default)
            => await _mediator.Send(command, context.CancellationToken);

        public async ValueTask<UserDto> SetNewPasswordAsync(SetNewPasswordCommand command, CallContext context = default)
            => await _mediator.Send(command, context.CancellationToken);
    }

    //Startup 
    public void ConfigureServices(IServiceCollection services)
    {
         services.AddCodeFirstGrpc(config =>
         {
             config.ResponseCompressionLevel = System.IO.Compression.CompressionLevel.Optimal;
             config.Interceptors.Add<ExceptionInterceptor>();
         });
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        // ...
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapGrpcService<UsersGrpcService>();
        });
        // ...
    }

    //Client - create of channel and service should be done by DI. 
    //Opening of channel & create service costs. 
    //Remember about it.
    using var grpc = _grpcFactory.CreateChannel(
        _settings.Users.Host,
        _settings.Users.Port);

    var service = grpc.CreateService<IUserGrpcService>();

    //Client - cosume method.
    var dto = await _service.CreateUserAsync(command);
    return dto;

Benchmark – environment

BenchmarkDotNet=v0.12.1, OS=macOS Catalina 10.15.3 (19D76) [Darwin 19.3.0]
Intel Core i7-8850H CPU 2.60GHz (Coffee Lake), 1 CPU, 12 logical and 6 physical cores
.NET Core SDK=3.1.301
  [Host]     : .NET Core 3.1.5 (CoreCLR 4.700.20.26901, CoreFX 4.700.20.27001), X64 RyuJIT  [AttachedDebugger]
  DefaultJob : .NET Core 3.1.5 (CoreCLR 4.700.20.26901, CoreFX 4.700.20.27001), X64 RyuJIT

Benchmark – how web communication should be implemented for the best performance?

Link: https://github.com/Rogaliusz/Grpc.Performance/blob/main/src/Grpc.Performance/Benchmarks/Implementation.cs

Dto Size ~ 2,5kb

As You see The clear winner is traditional method with created HttpClient. I want to focus our attention to cost of creating gRPC channel before every request, is expensive! As You see this is very simillar situation to create of instances HttpClients, is should be created with correct scope, btw. is good material for next article ;-)!

So now, when we know what is the most performant of communicate, every next benchmark will be execute with created gRPC channel & HttpClient ;-).

Benchmark – fetch dto.

Link: https://github.com/Rogaliusz/Grpc.Performance/blob/main/src/Grpc.Performance/Benchmarks/Series.cs

Dto Size ~ 2,5kb

Again, for small requests the old, good REST is clear winner :-(..

Benchmark – fetch collections.

Link: https://github.com/Rogaliusz/Grpc.Performance/blob/main/src/Grpc.Performance/Benchmarks/Collection.cs

Collection Size ~ 1,12 mb.
Pagination Size ~ 46 kb.

As we see for bigger payload gRPC is better solution, but probably case of send this kind large payload will be very rare :-(..

Benchmark – send items.

Link: https://github.com/Rogaliusz/Grpc.Performance/blob/main/src/Grpc.Performance/Benchmarks/Post.cs

BigCommand – flat model with few properties.
BigEventCommand – model with nested 20 elements collection.

So Again, larger payload = gRPC.

Summary

I’m very surprised of this result. I suspected that gRPC protocol will be clear winner in this battle, but I was wrong. For smaller requests old json format is clear winner, gRPC is good solution only for large payload.

Maybe this result is sponsored by my local network environment. In future I want to do this benchmark in Kubernetes cluster or communication between some endpoints in the web.

One thing is clear, JSON serialization in .Net core 3.1 is really, really fast. Team made great job, respect for them ;-)!

Edit

If You want to see how results are present in Azure Kubernetes Cluster, please check my new post about it 🙂