Sergi Gisbert

How to make an external API request in Blazor using Refit

2021-02-28T17:55:21Z

Blazor is the new development framework to develop SPA websites from Microsoft, and it is getting quite some attention lately. In this article, I'll do a simple demostration on how to make a request to an external API and displaying some data, using Refit library in an easy way.

Blazor allows to create website applications running C# on the client side, so effectively, most of the developers who consider ourselves mostly Backend devs, can now make the transition to become Full-Stack without the need of learning another client side framework like Angular or React. Also, there are already several UI control libraries for Blazor, some even free like Radzen. My last real-world application I developed myself using Blazor can be browsed at https://www.saboraemocion.com/

Making an introduction to Blazor is not the goal of this post, as there is already quite some good documentation on the topic to get you started pretty fast, and I recommend to start with the official docs and tutorials, at https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor.

What actually I'll be doing is to use a Blazor sample project to introduce you to Refit, which is, quoting themselves "The automatic type-safe REST library for .NET Core, Xamarin and .NET", meaning it will automatically create an API client for us, starting from an Interface definition. Refit will take care of the low-level details: HTTP requests, authetication, headers, serialization, type conversion, etc. I will use Refit to create a small currency exchange conversion tool, with the data coming from the free API at https://api.exchangeratesapi.io/ (you can see the service details at https://exchangeratesapi.io/)

The source code can be found at https://github.com/sgisbert/blazor-currencyexchange

Initial configuration

For this simple example, we are creating a SPA application with Blazor Server and .Net 5. It can also be done using a model based on client and Blazor WebAssembly. Check the differences between both hosting models here: https://docs.microsoft.com/aspnet/core/blazor/hosting-models

To create the new application, we can make use of the Visual Studio wizard, or simply, as per the Blazor tutorial, run the following command from the console:

dotnet new blazorserver -o BlazorApp

And to check that everything is working, we change folder to the "BlazorApp" created, and run:

dotnet watch run

this will compile the application, run it, and will keep watching the source code, to build and restart again every time a code change is made. To stop it, we just need to hit Ctrl+C.

When it completes building, it will display that the app is listening to http://localhost:5001 and our default browser will pop up on that address, showing the scaffolded app we just created:

Adding the business logic

The goal on this example will be listing the currency exchange values available for the current date. For that, we need to call the endpoint at https://api.exchangeratesapi.io/latest, that will return a JSON object like this:

{"rates":{"CAD":1.5307,"HKD":9.4121,"ISK":155.6,"PHP":58.846,"DKK":7.4368,"HUF":358.5,"CZK":25.849,"AUD":1.5445,"RON":4.8758,"SEK":10.033,"IDR":17094.81,"INR":88.0145,"BRL":6.5633,"RUB":89.6089,"HRK":7.578,"JPY":127.81,"THB":36.386,"CHF":1.0851,"SGD":1.6059,"PLN":4.483,"BGN":1.9558,"TRY":8.447,"CNY":7.8318,"NOK":10.2095,"NZD":1.6642,"ZAR":17.7391,"USD":1.2139,"MXN":24.7094,"ILS":3.97,"GBP":0.86508,"KRW":1339.59,"MYR":4.9048},"base":"EUR","date":"2021-02-19"}

Where we have all the different exchange prices against Euro for each currency, for the last published date.

The first thing I usually do is to create a new project on the solution to keep the business logic. This is not strictly necessary for this sample, but helps keeping up with best practices ;). To do so, I created a new .Net 5 library in the solution, called "Domain". In terms of "Domain Driven Development" (DDD) methodology, this will be our domain layer:

Again, full source code is on GitHub.

Once we got the new project, we will start creating the data model to work with. To generate the model in C#, we can use a tool like https://app.quicktype.io/, which will generate a complete C# class from the previous JSON data, optionally including helper methods to serialize and deserialize the data:

We will add the generated code to class Model/Rates.cs (we'll need to add a reference to the Nuget package Newtonsoft.Json):

namespace Domain.Model
{
    using System;
    using System.Collections.Generic;

    using System.Globalization;
    using Newtonsoft.Json;
    using Newtonsoft.Json.Converters;

    public partial class Rates
    {
        [JsonProperty("rates")]
        public Dictionary<string, double> RateList { get; set; }

        [JsonProperty("base")]
        public string Base { get; set; }

        [JsonProperty("date")]
        public DateTimeOffset Date { get; set; }
    }

    public partial class Rates
    {
        public static Rates FromJson(string json) => JsonConvert.DeserializeObject<Rates>(json, Converter.Settings);
    }

    public static class Serialize
    {
        public static string ToJson(this Rates self) => JsonConvert.SerializeObject(self, Converter.Settings);
    }

    internal static class Converter
    {
        public static readonly JsonSerializerSettings Settings = new JsonSerializerSettings
        {
            MetadataPropertyHandling = MetadataPropertyHandling.Ignore,
            DateParseHandling = DateParseHandling.None,
            Converters = {
                new IsoDateTimeConverter { DateTimeStyles = DateTimeStyles.AssumeUniversal }
            },
        };
    }
}

Next, we are using Refit to define the service that will make use of the API. For that, first thing is to include the nuget package Refit.HttpClientFactory in the project (Note: at the moment of writing this post, we are using Refit version 5.1.2. If you install version 6.x or higher it might not work straight away, because the default serializer engine has been changed from Newtonsoft.Json to System.Text.Json. I recommend to keep using 5.1.2 to follow the example without any issues, but have a look at the latest for new projects)

We add the following Interface to the Domain project Services/ICurrencyApi.cs:

using Domain.Model;
using Refit;
using System.Threading.Tasks;

namespace Domain.Services
{
    [Headers("Content-Type: application/json")]
    public interface ICurrencyApi
    {
        [Get("/latest")]
        Task<ApiResponse<Rates>> GetLatest();
    }
}

Where we are defining the request to the "latest" endpoint from the API, which will return an object of type "ApiResponse<Rates>", where ApiResponse will have the information of the request (http response code, errors, etc.) and the content of the response, which is our business model, Rates.

Next, we are adding the service that will make use of the Refit service, Services/ICurrencyService.cs:

using Domain.Model;
using Refit;
using System.Threading.Tasks;

namespace Domain.Services
{
    public interface ICurrencyService
    {
        Task<ApiResponse<Rates>> GetLatest();
    }
}

and its implementation, Services/CurrencyService.cs:

using Domain.Model;
using Refit;
using System.Threading.Tasks;

namespace Domain.Services
{
    public class CurrencyService : ICurrencyService
    {
        private readonly ICurrencyApi _api;

        public CurrencyService(ICurrencyApi api)
        {
            _api = api;
        }

        public async Task<ApiResponse<Rates>> GetLatest()
        {
            return await _api.GetLatest();
        }
    }
}

Finally, we will add a class to our library in charge of initializing the services we just created, so that netcore dependency injection is able to instantiate them correctly, DomainStartup.cs:

using Domain.Services;
using Microsoft.Extensions.DependencyInjection;
using Refit;
using System;

namespace Domain
{
    public static class DomainStartup
    {
        public static void InitDomain(this IServiceCollection services)
        {
            services.AddScoped<ICurrencyService, CurrencyService>();

            services.AddRefitClient<ICurrencyApi>()
                    .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://api.exchangeratesapi.io/"))
                    .SetHandlerLifetime(TimeSpan.FromMinutes(2));
        }
    }
}

In this case, we initialize our CurrencyService, and make use of method AddRefitClient to tell Refit the initialization values for the API, and the base URL of the service.

Using the service in the Blazor application

Until now, we have not modified anything on the Blazor application we created at the beginning. At this point, we will add some code to show the list of currencies and their exchange rate.

First step will be modifying the Startup.cs to initialize the services from the Domain:

using Domain;

...

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
    services.AddServerSideBlazor();
    services.AddSingleton<WeatherForecastService>();

    services.InitDomain();
}

Next, we create a new Razor component to host the page with the list of currencies, Pages/Currency.razor:

@page "/currency"

@using Domain.Services
@using Domain.Model
@inject ICurrencyApi CurrencyService


<h1>Currency converter</h1>

@if (rates == null)
{
    <p><em>Loading...</em></p>
    <p>@error</p>
}
else
{
    <h3>1 @rates.Base is worth as of @rates.Date.ToString("d"):</h3>
    <table class="table">
        <thead>
            <tr>
                <th>Currency</th>
                <th>Rate</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var rate in rates.RateList)
            {
                <tr>
                    <td>@rate.Key</td>
                    <td>@rate.Value</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private Rates rates;
    private string error;

    protected override async Task OnInitializedAsync()
    {
        var response = await CurrencyService.GetLatest();
        if (response.IsSuccessStatusCode)
        {
            rates = response.Content;
        }
        else
            error = response.Error.Content;
    }
}

In this page, we first inject our domain service:

@inject ICurrencyApi CurrencyService

During the component initialization, OnInitializedAsync(), we call the service to get the data:

var response = await CurrencyService.GetLatest();

If the request is succesful, we initialize the local variable rates, which will be the one used to display the data on screen:

rates = response.Content;

Finally, let's add a link in the menu to our newly created page, modifying Shared/NavMenu.razor:

<li class="nav-item px-3">
    <NavLink class="nav-link" href="currency">
        <span class="oi oi-list-rich" aria-hidden="true"></span> Currency
    </NavLink>
</li>

If everything goes fine, and we still have the app running with "dotnet watch run", we can go back to the browser and we will see the new option in the menu. If not, we just launch the application and wait for the browser to run. Clicking on the menu, we should see the list of currencies exchange rates at the current date:

Summary

Blazor is becoming a very interesting framework to develop SPA and dynamic web applications, same style as React, Angular, etc. specially for developers specialized on backend and C#.
Refit is a library to dynamically create REST APIs clients with minimum effort, but very powerful at the same time.

In the following posts, I will keep showing some features from Blazor and RefitEn próximos posts seguiré mostrando algunas funcionalidades de Blazor y Refit, going deeper a bit more on this sample application to calculate currency exchange rates.

Cómo hacer una petición a un API externa con Blazor y Refit

2021-02-21T17:01:30Z

Blazor es el nuevo framework de desarrollo para crear SPA que ofrece Microsoft y que está teniendo mucho crecimiento en los últimos tiempos. En este artículo haremos una pequeña demostración de cómo hacer una llamada a un API externa y mostrar los datos recibidos, utilizando Refit de una manera muy sencilla.

Blazor permite crear aplicaciones en el lado del cliente con C#, por lo que consigue que muchos desarrolladores que nos consideramos más de Backend, podamos dar el salto a Full-Stack sin necesidad de aprender otros frameworks como Angular o React. Asímismo, ya existen varias librerías de controles de UI para Blazor, incluso algunas gratuitas como las de Radzen. La última aplicación real que he desarrollado con Blazor la podéis ver en https://www.saboraemocion.com/

No es el objetivo de este post hacer una introducción a Blazor, ya que existe muy buena documentación y tutoriales oficiales que recomiendo seguir. Podéis empezar en https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor.

En cambio, voy a aprovechar un proyecto con Blazor para escribir sobre Refit, una librería que nos permite crear automáticamente un cliente para consumir un API REST externa a partir de la definición de un Interface. Refit se encarga del resto: comunicación Http, autenticación, cabeceras, serialización, conversión de tipos, etc. Usaremos Refit para crear un pequeño conversor de moneda, con los datos ofrecidos por la API gratuita https://api.exchangeratesapi.io/ (ver detalles del servicio en https://exchangeratesapi.io/)

El código fuente de ejemplo lo podéis encontrar en https://github.com/sgisbert/blazor-currencyexchange

Configuración inicial

Para este ejemplo sencillo, crearemos una aplicación SPA con Blazor Server con .Net 5. También se puede desarrollar con un modelo basado en cliente con Blazor WebAssembly. Podéis ver las diferencias entre ambos modos de hospedaje en https://docs.microsoft.com/aspnet/core/blazor/hosting-models

Para crear nuestra aplicación, podemos usar el asistente de Visual Studio, o simplemente, siguiendo los pasos del tutorial de Blazor, lanzar el siguiente comando desde PowerShell:

dotnet new blazorserver -o BlazorApp

Y para comprobar que todo funciona, entramos en la carpeta "BlazorApp" que se ha generado y ejecutamos:

dotnet watch run

que compilará y ejecutará la aplicación, y volverá a compilar y reiniciarla cada vez que el código fuente cambie. Para detenerla basta con pulsar Ctrl+C.

Cuando termine de compilar mostrará que está escuchando en http://localhost:5001 y se abrirá el navegador con esa dirección, mostrando la aplicación que acabamos de crear:

Añadiendo la lógica de negocio

El objetivo de este ejemplo será listar los valores de cambio de monedas disponibles para el día de hoy. Para ello, haremos una llamada al endpoint https://api.exchangeratesapi.io/latest, que nos devuelve un objeto JSON como este:

{"rates":{"CAD":1.5307,"HKD":9.4121,"ISK":155.6,"PHP":58.846,"DKK":7.4368,"HUF":358.5,"CZK":25.849,"AUD":1.5445,"RON":4.8758,"SEK":10.033,"IDR":17094.81,"INR":88.0145,"BRL":6.5633,"RUB":89.6089,"HRK":7.578,"JPY":127.81,"THB":36.386,"CHF":1.0851,"SGD":1.6059,"PLN":4.483,"BGN":1.9558,"TRY":8.447,"CNY":7.8318,"NOK":10.2095,"NZD":1.6642,"ZAR":17.7391,"USD":1.2139,"MXN":24.7094,"ILS":3.97,"GBP":0.86508,"KRW":1339.59,"MYR":4.9048},"base":"EUR","date":"2021-02-19"}

Donde tenemos los diferentes precios de cada moneda con respecto al Euro para la última fecha publicada.

Lo primero que haremos será crear un nuevo proyecto en la solución para albergar nuestra lógica de negocio. Esto no es imprescindible para este ejemplo, pero ayuda a mantener las buenas prácticas ;). Para ello, creamos una nueva librería basada en .Net 5 a la solución, y la llamaremos "Domain". En términos de la metodología "Domain Driven Development" (DDD), esta será nuestra capa de Dominio:

El código fuente completo de este paso lo puedes encontrar en GitHub.

Una vez tenemos el nuevo proyecto, empezaremos creando el modelo de datos con el que vamos a trabajar. Para generar el modelo en C#, podemos usar una herramienta como https://app.quicktype.io/, que a partir del JSON anterior nos va a generar una clase completa en C#, incluso con la opción de añadir métodos auxiliares para serializar y deserializar los datos:

Añadimos el código generado a la clase Model/Rates.cs (necesitaremos añadir una referencia al paquete de Nuget Newtonsoft.Json):

namespace Domain.Model
{
    using System;
    using System.Collections.Generic;

    using System.Globalization;
    using Newtonsoft.Json;
    using Newtonsoft.Json.Converters;

    public partial class Rates
    {
        [JsonProperty("rates")]
        public Dictionary<string, double> RateList { get; set; }

        [JsonProperty("base")]
        public string Base { get; set; }

        [JsonProperty("date")]
        public DateTimeOffset Date { get; set; }
    }

    public partial class Rates
    {
        public static Rates FromJson(string json) => JsonConvert.DeserializeObject<Rates>(json, Converter.Settings);
    }

    public static class Serialize
    {
        public static string ToJson(this Rates self) => JsonConvert.SerializeObject(self, Converter.Settings);
    }

    internal static class Converter
    {
        public static readonly JsonSerializerSettings Settings = new JsonSerializerSettings
        {
            MetadataPropertyHandling = MetadataPropertyHandling.Ignore,
            DateParseHandling = DateParseHandling.None,
            Converters = {
                new IsoDateTimeConverter { DateTimeStyles = DateTimeStyles.AssumeUniversal }
            },
        };
    }
}

A continuación, usaremos Refit para definir el servicio que realice el acceso a la API. Para ello, primero incluimos el paquete de Nuget Refit.HttpClientFactory en nuestra solución (Nota: en el momento de escribir este ejemplo, usamos la versión 5.1.2 de Refit. Si instalas la versión 6.x puede que no funcione correctamente porque se ha cambiado el motor de serialización por defecto de Newtonsoft.Json a System.Text.Json. Recomiendo instalar la versión de este ejemplo para seguirlo sin problemas, pero usar la última para nuevos desarrollos)

Añadimos el siguiente Interface al proyecto de Domain Services/ICurrencyApi.cs:

using Domain.Model;
using Refit;
using System.Threading.Tasks;

namespace Domain.Services
{
    [Headers("Content-Type: application/json")]
    public interface ICurrencyApi
    {
        [Get("/latest")]
        Task<ApiResponse<Rates>> GetLatest();
    }
}

Donde definimos la llamada al endpoint "latest" de la API, que nos va a devolver un objeto "ApiResponse<Rates>", donde ApiResponse contendrá información de la petición (http response code, errores, etc. y el contenido de la misma, que es nuestro objeto de negocio, Rates.

Seguidamente, añadiremos el servicio que hará uso del servicio de Refit, Services/ICurrencyService.cs:

using Domain.Model;
using Refit;
using System.Threading.Tasks;

namespace Domain.Services
{
    public interface ICurrencyService
    {
        Task<ApiResponse<Rates>> GetLatest();
    }
}

y su implementación, Services/CurrencyService.cs:

using Domain.Model;
using Refit;
using System.Threading.Tasks;

namespace Domain.Services
{
    public class CurrencyService : ICurrencyService
    {
        private readonly ICurrencyApi _api;

        public CurrencyService(ICurrencyApi api)
        {
            _api = api;
        }

        public async Task<ApiResponse<Rates>> GetLatest()
        {
            return await _api.GetLatest();
        }
    }
}

Finalmente, añadiremos una clase a nuestra librería que se encargue de inicializar los servicios que hemos creado, para que la inyección de dependencias sea capaz de inicializarlos correctamente, DomainStartup.cs:

using Domain.Services;
using Microsoft.Extensions.DependencyInjection;
using Refit;
using System;

namespace Domain
{
    public static class DomainStartup
    {
        public static void InitDomain(this IServiceCollection services)
        {
            services.AddScoped<ICurrencyService, CurrencyService>();

            services.AddRefitClient<ICurrencyApi>()
                    .ConfigureHttpClient(c => c.BaseAddress = new Uri("https://api.exchangeratesapi.io/"))
                    .SetHandlerLifetime(TimeSpan.FromMinutes(2));
        }
    }
}

En este caso, inicializamos nuestro CurrencyService, y hacemos uso de la extensión AddRefitClient para indicarle a Refit los parámetros de inicialización del API, como la URL base del servicio.

Usamos la lógica en la aplicación Blazor

Hasta el momento no hemos modificado para nada la aplicación Blazor que hemos creado al principio. Ahora añadiremos el código para mostrar el listado de monedas y su tipo de cambio.

Lo primero que hacemos es modificar Startup.cs para inicializar los servicios que hemos creado en el Dominio:

using Domain;

...

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
    services.AddServerSideBlazor();
    services.AddSingleton<WeatherForecastService>();

    services.InitDomain();
}

A continuación, creamos un nuevo componente razor que albergará la página con el listado de monedas, Pages/Currency.razor:

@page "/currency"

@using Domain.Services
@using Domain.Model
@inject ICurrencyApi CurrencyService


<h1>Currency converter</h1>

@if (rates == null)
{
    <p><em>Loading...</em></p>
    <p>@error</p>
}
else
{
    <h3>1 @rates.Base is worth as of @rates.Date.ToString("d"):</h3>
    <table class="table">
        <thead>
            <tr>
                <th>Currency</th>
                <th>Rate</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var rate in rates.RateList)
            {
                <tr>
                    <td>@rate.Key</td>
                    <td>@rate.Value</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private Rates rates;
    private string error;

    protected override async Task OnInitializedAsync()
    {
        var response = await CurrencyService.GetLatest();
        if (response.IsSuccessStatusCode)
        {
            rates = response.Content;
        }
        else
            error = response.Error.Content;
    }
}

En esta página, primero estamos inyectando nuestro servicio de dominio:

@inject ICurrencyApi CurrencyService

Durante la inicialización del componente, OnInitializedAsync(), llamamos al servicio externo para obtener los datos:

var response = await CurrencyService.GetLatest();

Si la llamada ha sido correcta, inicializamos el valor de la variable local rates, que será la que utilicemos para presentar los datos en pantalla:

rates = response.Content;

Por último, vamos a añadir un enlace en el menú a nuestra nueva página, modificando Shared/NavMenu.razor:

<li class="nav-item px-3">
    <NavLink class="nav-link" href="currency">
        <span class="oi oi-list-rich" aria-hidden="true"></span> Currency
    </NavLink>
</li>

Si todo ha ido bien, y seguimos teniendo la aplicación lanzada con "dotnet watch run", volvemos al navegador y veremos la nueva opción en el menú. Si no, lanzamos la aplicación y esperamos a que se cargue en el navegador. Al pulsar sobre el menú, veremos nuestro listado de monedas frente al euro en la fecha de hoy:

Conclusiones

Blazor se está convirtiendo en un framework muy interesante para el desarrollo de SPA y aplicaciones web dinámicas, al estilo de Angular, React, etc. especialmente para los desarrolladores especializados en backend y C#.
Refit es una librería para crear dinámicamente clientes de APIs REST sin ningún esfuerzo, pero muy potente a su vez.

En próximos posts seguiré mostrando algunas funcionalidades de Blazor y Refit, profundizando un poco más en este ejemplo de aplicación calcular los tipos de cambio entre monedas.

Parallel programming in C# with class Parallel

2021-02-13T16:21:49Z

Disclaimer: the methods and code examples in this article are the fruit of my own investigation and self learning, and in no means these are ready to be used in a real, production environment. Use at your own risk. To learn more about parallel and synchronous programming, I recommend reading the official documentation at: https://docs.microsoft.com/dotnet/standard/parallel-processing-and-concurrency

This post is part of a series of 3 articles about performace improvement with parallel programming:

1. Improve the performance with asynchronous functions to run processes in parallel
2. Make use of ConcurrentBag to store the results from asynchronous processes
3. Parallel programming in C# with class Parallel (this article)

Following up with the series of posts about async programming and performance improvements using Tasks for process parallelization, in this one I am introducing a new option, using Parallel class available in .Net, and I will compare it with the previous examples, where we run a process that returns a list of 10 random numbers between 1 and 100, and we cut it down to 0,6s execution time, from the starting 2s of the synchronous process:

Result: 82,83,88,99,57,71,13,54,18,40
Completed: 00:00:00.6276547

You can find the source code of this examples on Github: https://github.com/sgisbert/parallelization

At this examples, we used Task.Run() to execute a process in a new thread. It is important to understand that the use of Task to create new threads is limited to the number of cores available, and the excesive use of these can lead to a not so efficient use of system resources. To better understand these concepts, I recommend further reading: https://www.pluralsight.com/guides/using-task-run-async-await#module-knowthenatureofyourasynchronousoperation

The use of async/await pattern is specially recommended with libraries or API calls that already offer async methods, without the need to use Task.Run() to create them. Good examples of this are HttpClient or FileStream, that offer I/O async methods and we can take full benefit of async programming.

If still we have a use case like in the example, where you need to execute the same logic over several objects, we can use the class Parallel, and see how it performs, in comparison with Task.WaitAll() or Task.WhenAll().

Task.WaitAll() vs Task.WhenAll()

There are two different ways to wait for all our tasks to complete:

await Task.WhenAll(tasks.ToArray());

and

Task.WaitAll(tasks.ToArray());

and it is interesting to know the differences between both. In terms of performance, the process takes a very similar amount of time to complete: 0,6s, but there are some aspects worth to be noted:

Task.WaitAll()

The main UI execution thread is blocked until all the tasks are completed, so it does not return a Task. This means that if we have a UI dependant application, it could freeze until the execution ends.
If there are any exceptions thrown, it will throw an AggregateException with all the exceptions together.

await Task.WhenAll()

The main thread is not blocked, so this would be the recommended approach for a UI application and async methods, as it actually returns a Task.
If there are any exceptions, only the first one is returned.

In this article, you can explore deeper the differences between both methods: https://www.infoworld.com/article/3152735/when-to-use-taskwaitall-vs-taskwhenall-in-net.html

Using Parallel class

Another way to make use of parallel programming advantages, is with class Parallel in .Net (more info in the official documentation)

First thing to do with our code will be to transform the process so it does not need to use Task.Run(), but keeping the compatibility with Task to be able to compare both results. So, let's modify the method in the following way (see full source code on GitHub):

private static async Task Process(int id, ConcurrentBag<int> cb)
{
    await Task.Run(() =>
    {
        CoreProcess(id, cb);
    });
}

private static void CoreProcess(int id, ConcurrentBag<int> cb)
{
    Stopwatch timer = new Stopwatch();
    timer.Start();
    Random random = new Random();
    Thread.Sleep(200);

    int number = random.Next(1, 100);
    cb.Add(number);

    Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Process {id}: {timer.Elapsed}");
}

We also added the value of Thread.CurrentThread.ManagedThreadId to the console output to check the Threads being created.

This way, we can call our process both in sync or async way.

Parallel.ForEach()

Now we can add the following code, using Parallel.ForEach() to run the synchronous process, but being parallelized (see full source code on GitHub):

timer.Restart();
ConcurrentBag<int> cb2 = new ConcurrentBag<int>();
var sourceCollection = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
Parallel.ForEach(sourceCollection, (id) =>
{
    CoreProcess(id, cb2);
});
Console.WriteLine($"Result: {string.Join(",", cb2)}");
Console.WriteLine($"Completed: {timer.Elapsed}");
Console.WriteLine();

And let's compare the results:

Task.WaitAll()

[6] Process 2: 00:00:00.2028313
[5] Process 1: 00:00:00.2039001
[4] Process 0: 00:00:00.2063105
[7] Process 3: 00:00:00.2027921
[4] Process 5: 00:00:00.2006033
[7] Process 7: 00:00:00.2006397
[5] Process 6: 00:00:00.2006732
[6] Process 4: 00:00:00.2007073
[7] Process 8: 00:00:00.2001104
[5] Process 9: 00:00:00.2009985

Result: 15,49,52,76,90,1,71,67,37,23
Completed: 00:00:00.6398704

Parallel.ForEach()

[6] Process 9: 00:00:00.2011420
[5] Process 3: 00:00:00.2012138
[1] Process 1: 00:00:00.2013376
[4] Process 7: 00:00:00.2011324
[7] Process 5: 00:00:00.2011974
[1] Process 2: 00:00:00.2004285
[4] Process 8: 00:00:00.2004063
[7] Process 6: 00:00:00.2005255
[6] Process 10: 00:00:00.2006825
[5] Process 4: 00:00:00.2006454
Result: 50,82,38,39,37,96,80,48,95,90
Completed: 00:00:00.4507518

The task run with Parallel has decreased the time to 0,45s in front of the 0,6s of Task. We got a performance improvement without having to make use of Task.Run(), which could bring up potential problems with the use of system resources.

Parallel.Invoke()

Parallel offers also another alternative to execute parallel tasks, with method Invoke(). To test it, let's add the following code lines (see full source code on Github):

timer.Restart();
ConcurrentBag<int> cb3 = new ConcurrentBag<int>();
List<Action> actions = new List<Action>();
foreach (var i in sourceCollection)
{
    actions.Add(() => CoreProcess(i, cb3));
}
Parallel.Invoke(actions.ToArray());
Console.WriteLine($"Result: {string.Join(",", cb3)}");
Console.WriteLine($"Completed: {timer.Elapsed}");

With the following results:

[4] Process 3: 00:00:00.2008078
[6] Process 4: 00:00:00.2008435
[5] Process 5: 00:00:00.2007954
[7] Process 2: 00:00:00.2008161
[1] Process 1: 00:00:00.2009441
[7] Process 8: 00:00:00.2001254
[5] Process 6: 00:00:00.2001896
[4] Process 7: 00:00:00.2001298
[8] Process 10: 00:00:00.2033235
[6] Process 9: 00:00:00.2089627
Result: 55,26,74,29,32,45,71,46,39,90
Completed: 00:00:00.4121676

In this case, Invoke() reduces the time up to nearly 0,4s.

Conclusions

Analize deeply each situation, understanding how async methods work and the differences between Task.WaitAll y Task.WhenAll, to make use of them correctly on every situation.
Know other alternatives like Parallel to improve the application performance.
Don't take any of these examples for granted. Make your own performance tests and check on every case what solution works best for you

Programación paralela en C# con la clase Parallel

2021-02-13T16:15:58Z

Disclaimer: los métodos y ejemplos de código de este artículo son fruto de mi propia investigación y aprendizaje autónomo, y en ningún caso están preparados para su utilización en código real de producción. El autor no se hace responsable del uso de estos ejemplos. Para más información sobre programación paralela y asíncrona y sus connotaciones, recomiendo acceder a la documentación oficial: https://docs.microsoft.com/dotnet/standard/parallel-processing-and-concurrency

Este post forma parte de una serie de 3 artículos sobre mejoras de rendimiento utilizando programación paralela:

1. Mejorar el rendimiento con funciones asíncronas para la ejecución de procesos en paralelo
2. Utilizar ConcurrentBag para almacenar el resultado de métodos asíncronos
3. Programación paralela en C# con la clase Parallel (Este artículo)

Siguiendo con la serie de posts dedicados a la programación asíncrona y a la mejora de rendimiento utilizando Task para la paralelización de procesos, en este caso introducimos una nueva posibilidad utilizando la clase Parallel que nos ofrece .Net, y la comparamos con las ejecuciones anteriores, donde recordamos que se ejecutaba un proceso que nos devolvía una lista de 10 números aleatorios entre 1 y 100, y lo dejamos en unos 0,6s de tiempo de ejecución, frente a los 2s originales de un proceso síncrono:

Result: 82,83,88,99,57,71,13,54,18,40
Completed: 00:00:00.6276547

El código fuente de ejemplo mostrado lo podéis encontrar en Github: https://github.com/sgisbert/parallelization

En estos ejemplos, usábamos Task.Run() para ejecutar el proceso en un nuevo hilo. Es importante entender que el uso de Task para crear nuevos hilos de ejecución está limitado por el número de cores que tengamos en el procesador, y el uso excesivo de estos puede llevar a un uso poco eficiente de los recursos del sistema. Para entender más estos conceptos, recomiendo leer este artículo: https://www.pluralsight.com/guides/using-task-run-async-await#module-knowthenatureofyourasynchronousoperation

El uso de async/await es especialmente recomendable junto con librerías o APIs que ofrecen métodos asíncronos sin necesidad de acudir a Task.Run() para crearlos. Buenos ejemplos de este caso son HttpClient o FileStream, que ofrecen métodos de I/O asíncronos donde se pueden aprovechar las virtudes de la programación asíncrona.

Si aún así tenemos un caso como el del ejemplo, donde tenemos que realizar un mismo procesamiento sobre múltiples instancias diferentes, podemos aprovechar la clase Parallel, y ver cómo se comporta en comparación con Task.WaitAll() o Task.WhenAll().

Task.WaitAll() vs Task.WhenAll()

Existen dos maneras de esperar a que todas nuestras tareas terminen de ejecutarse:

await Task.WhenAll(tasks.ToArray());

Task.WaitAll(tasks.ToArray());

Y es interesante conocer la diferencia entre las dos. En términos de rendimiento, en ambos casos el proceso dura un tiempo similar: 0,6s, pero hay ciertos matices interesantes a conocer:

Task.WaitAll()

Bloquea el thread principal de ejecución hasta que todas las tareas terminen, por lo que no devuelve una Task. Esto significa que si tenemos una aplicación con UI, éste quedará bloqueado hasta que termine la ejecución
Si se producen excepciones en una o varias tareas, lanzará una AggregateException con todas las excepciones que se hayan producido

await Task.WhenAll()

No bloquea el thread principal, por lo que sería el método recomendado para aplicación con UI y métodos async, ya que sí devuelve una Task.
Si se producen excepciones, sólo lanzará la primera que ocurra.

En este artículo se detalla con más nivel de detalle las diferencias entre ambos métodos: https://www.infoworld.com/article/3152735/when-to-use-taskwaitall-vs-taskwhenall-in-net.html

Utilizando la clase Parallel

Otra manera de aprovechar las ventajas de la computación paralela, es utilizar la clase Parallel de .Net (más info en la documentación oficial)

Lo primero que haremos con nuestro código de ejemplo será transformar nuestro proceso para que no necesite utilizar Task.Run(), pero manteniendo la compatibilidad con Task para comparar ambos resultados. Para ello, modificamos el método process de la siguiente manera (ver archivo completo en GitHub):

private static async Task Process(int id, ConcurrentBag<int> cb)
{
    await Task.Run(() =>
    {
        CoreProcess(id, cb);
    });
}

private static void CoreProcess(int id, ConcurrentBag<int> cb)
{
    Stopwatch timer = new Stopwatch();
    timer.Start();
    Random random = new Random();
    Thread.Sleep(200);

    int number = random.Next(1, 100);
    cb.Add(number);

    Console.WriteLine($"[{Thread.CurrentThread.ManagedThreadId}] Process {id}: {timer.Elapsed}");
}

Hemos añadido también el valor de Thread.CurrentThread.ManagedThreadId a la salida por consola para comprobar los Threads que se crean.

De esta manera, podemos llamar a nuestro proceso tanto de manera asíncrona como síncrona.

Parallel.ForEach()

Añadimos el siguiente código, que utiliza Parallel.ForEach() para lanzar el proceso síncrono, pero usando paralelismo (ver archivo completo en GitHub):

timer.Restart();
ConcurrentBag<int> cb2 = new ConcurrentBag<int>();
var sourceCollection = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
Parallel.ForEach(sourceCollection, (id) =>
{
    CoreProcess(id, cb2);
});
Console.WriteLine($"Result: {string.Join(",", cb2)}");
Console.WriteLine($"Completed: {timer.Elapsed}");
Console.WriteLine();

Y comparamos los resultados:

Task.WaitAll()

[6] Process 2: 00:00:00.2028313
[5] Process 1: 00:00:00.2039001
[4] Process 0: 00:00:00.2063105
[7] Process 3: 00:00:00.2027921
[4] Process 5: 00:00:00.2006033
[7] Process 7: 00:00:00.2006397
[5] Process 6: 00:00:00.2006732
[6] Process 4: 00:00:00.2007073
[7] Process 8: 00:00:00.2001104
[5] Process 9: 00:00:00.2009985

Result: 15,49,52,76,90,1,71,67,37,23
Completed: 00:00:00.6398704

Parallel.ForEach()

[6] Process 9: 00:00:00.2011420
[5] Process 3: 00:00:00.2012138
[1] Process 1: 00:00:00.2013376
[4] Process 7: 00:00:00.2011324
[7] Process 5: 00:00:00.2011974
[1] Process 2: 00:00:00.2004285
[4] Process 8: 00:00:00.2004063
[7] Process 6: 00:00:00.2005255
[6] Process 10: 00:00:00.2006825
[5] Process 4: 00:00:00.2006454
Result: 50,82,38,39,37,96,80,48,95,90
Completed: 00:00:00.4507518

La tarea ejecutada con Parallel ha bajado el tiempo a 0,45s frente a los 0,6s de Task. Hemos obtenido una mejora de rendimiento sin tener que ejecutar Task.Run() que puede ocasionar problemas con el uso de los recursos disponibles.

Parallel.Invoke()

Parallel nos ofrece otra alternativa adicional para invocar tareas en paralelo, con el método Invoke(). Para probar su uso, añadimos las siguientes líneas de código (ver archivo completo en Github):

timer.Restart();
ConcurrentBag<int> cb3 = new ConcurrentBag<int>();
List<Action> actions = new List<Action>();
foreach (var i in sourceCollection)
{
    actions.Add(() => CoreProcess(i, cb3));
}
Parallel.Invoke(actions.ToArray());
Console.WriteLine($"Result: {string.Join(",", cb3)}");
Console.WriteLine($"Completed: {timer.Elapsed}");

Con los siguientes resultados:

[4] Process 3: 00:00:00.2008078
[6] Process 4: 00:00:00.2008435
[5] Process 5: 00:00:00.2007954
[7] Process 2: 00:00:00.2008161
[1] Process 1: 00:00:00.2009441
[7] Process 8: 00:00:00.2001254
[5] Process 6: 00:00:00.2001896
[4] Process 7: 00:00:00.2001298
[8] Process 10: 00:00:00.2033235
[6] Process 9: 00:00:00.2089627
Result: 55,26,74,29,32,45,71,46,39,90
Completed: 00:00:00.4121676

En este caso, Invoke() reduce el tiempo hasta casi 0,4s.

Conclusiones

Analiza bien cada situación, entendiendo cómo funcionan los métodos asíncronos y las diferencias entre Task.WaitAll y Task.WhenAll, para utilizarlos correctamente en cada caso
Conoce otras alternativas como Parallel para mejorar el rendimiento de tus aplicaciones
No te creas los resultados de estos ejemplos. Haz pruebas de rendimiento por ti mismo y comprueba en cada caso qué te funciona mejor

Make use of ConcurrentBag to store the results from asynchronous processes

2021-02-13T16:29:50Z

This post is part of a series of 3 articles about performace improvement with parallel programming:

1. Improve the performance with asynchronous functions to run processes in parallel
2. Make use of ConcurrentBag to store the results from asynchronous processes (this article)
3. Parallel programming in C# with class Parallel

From my previous post about parallelizing process execution, I am extending the sample there to show how we can get that different processes in parallel can combine their results into the same object, without the asynchronous execution being a problem. In this case, we are going to get all the results from the execution in the same data list.

Source code in this article can be found on Github: https://github.com/sgisbert/parallelization

Starting point

In the previous post we managed to reduce the processing time from 2 seconds down to 0.6 seconds, althoug actually our method was not returning any result. For this sample, I am modifying it to make it return a random number between 1 and 100, while we keep the delay to show the execution time.

Let's modify the Process() method to return an integer (see full file on Github):

private static async Task<int> Process(int id)
{
    var number = await Task<int>.Run(() =>
    {
        Stopwatch timer = new Stopwatch();
        timer.Start();
        Random random = new Random();
        Thread.Sleep(200);

        int number = random.Next(1,10);

        Console.WriteLine($"Process {id}: {timer.Elapsed}");
        return number;
    });
    return number;
}

And add the necessary code to get the results in the main thread:

List<Task<int>> tasks = new List<Task<int>>();
for (int i = 0; i < 10; i++)
{
    tasks.Add(Process(i));
}
Task.WaitAll(tasks.ToArray());

List<int> results = new List<int>();
foreach (var task in tasks)
{
    results.Add(task.Result);
}

Note that changing the return type for Process() to Task<int>, we also need to change it for the list where we are storing the tasks that are being executed to as well to List<Task<int>>, so we can access later to the result with task.Result.

The execution result is as follows:

Process 0: 00:00:00.2077483
Process 1: 00:00:00.2076874
Process 3: 00:00:00.2074275
Process 2: 00:00:00.2057897
Process 7: 00:00:00.2097799
Process 6: 00:00:00.2101881
Process 5: 00:00:00.2103866
Process 4: 00:00:00.2109039
Process 9: 00:00:00.2004370
Process 8: 00:00:00.2006408

Result: 76,2,79,86,12,45,27,17,55,5
Completed: 00:00:00.6971794

In this sample, we are processing all the results after all the tasks have finalized the execution. For this simple example, the second foreach loop has increased the execution time in almost one tenth, getting closer to 0.7s from the originally 0.6s. Imagine a more complex case where you should analyze hundreds or thousands results, it is possible you would lose most of the performance gains you got from parallelizing the process.

Getting the results already processed

So that we don't need to post process the results from the asynchronous methods in a loop, we can make use of concurrent data types, which are thread-safe, like ConcurrentBag<T>. There are also concurrent versions for Dictionary, Queue and Stack. With these data types, each process will add its results directly to the same ConcurrentBag as the others, so once back to the main thread, there's no need to loop over the results again.

To do so, let's add the ConcurrentBag as a parameter to our Process() method (see full file on Github):

private static async Task Process(int id, ConcurrentBag<int> cb)
{
    await Task.Run(() =>
    {
        Stopwatch timer = new Stopwatch();
        timer.Start();
        Random random = new Random();
        Thread.Sleep(200);

        int number = random.Next(1,100);
        cb.Add(number);

        Console.WriteLine($"Process {id}: {timer.Elapsed}");
    });
}

So we don't need to return a Task<int>, nor process again the results in the main thread, but we can make use of them directly from the ConcurrentBag:

static async Task Main(string[] args)
{
    ConcurrentBag<int> cb = new ConcurrentBag<int>();
    Stopwatch timer = new Stopwatch();
    timer.Start();

    List<Task> tasks = new List<Task>();
    for (int i = 0; i < 10; i++)
    {
        tasks.Add(Process(i, cb));
    }
    Task.WaitAll(tasks.ToArray());

    Console.WriteLine();
    Console.WriteLine($"Result: {string.Join(",", cb)}");
    Console.WriteLine($"Completed: {timer.Elapsed}");
}

Back to the results:

Process 1: 00:00:00.2029103
Process 2: 00:00:00.2028785
Process 0: 00:00:00.2029188
Process 3: 00:00:00.2028485
Process 5: 00:00:00.2007397
Process 7: 00:00:00.2007120
Process 6: 00:00:00.2007211
Process 4: 00:00:00.2008456
Process 9: 00:00:00.2001557
Process 8: 00:00:00.2007588

Result: 82,83,88,99,57,71,13,54,18,40
Completed: 00:00:00.6276547

And we are back again to be closer to the 0.6 seconds than before, once we removed the unnecessary loop to process the results.

Conclusions

It is possible to execute processes in parallel and get the results grouped in the same object. This will avoid the need to post-process the results, which would add an unnecessary execution time.
There are thread-safe data types for collections that can be used to store the results from asynchronous tasks, like ConcurrentBag, ConcurrentDictionary, ConcurrentQueue or ConcurrentStack. Learning how to use them will give us better options to improve our applications.

Utilizar ConcurrentBag para almacenar el resultado de métodos asíncronos

2021-02-13T16:11:11Z

Disclaimer: los métodos y ejemplos de código de este artículo son fruto de mi propia investigación y aprendizaje autónomo, y en ningún caso están preparados para su utilización en código real de producción. El autor no se hace responsable del uso de estos ejemplos. Para más información sobre programación paralela y asíncrona y sus connotaciones, recomiendo acceder a la documentación oficial: https://docs.microsoft.com/es-es/dotnet/standard/parallel-processing-and-concurrency

Este post forma parte de una serie de 3 artículos sobre mejoras de rendimiento utilizando programación paralela:

1. Mejorar el rendimiento con funciones asíncronas para la ejecución de procesos en paralelo
2. Utilizar ConcurrentBag para almacenar el resultado de métodos asíncronos (Este artículo)
3. Programación paralela en C# con la clase Parallel

Al hilo del post anterior sobre ejecución paralela de tareas, voy a ampliar el ejemplo para demostrar como podemos conseguir que diferentes procesos en paralelo puedan combinar el resultado en un mismo objeto, sin que la ejecución asíncrona sea un problema. En este caso, vamos a obtener los resultados del procesamiento en una misma lista de datos.

El código fuente de ejemplo mostrado lo podéis encontrar en Github: https://github.com/sgisbert/parallelization

Punto de partida

En el post anterior conseguimos reducir el tiempo de procesamiento de 2 segundos a 0,6 segundos, aunque en realidad nuestra función no devolvía ningún resultado. Para este ejemplo, vamos a modificarla para que devuelva un número aleatorio entre 1 y 100, mientras mantenemos el retardo para ilustrar el tiempo de ejecución.

Modificamos el método Process() para devolver un entero (ver archivo completo en Github):

private static async Task<int> Process(int id)
{
    var number = await Task<int>.Run(() =>
    {
        Stopwatch timer = new Stopwatch();
        timer.Start();
        Random random = new Random();
        Thread.Sleep(200);

        int number = random.Next(1,10);

        Console.WriteLine($"Process {id}: {timer.Elapsed}");
        return number;
    });
    return number;
}

Y añadimos el código necesario para recoger los resultados en el hilo principal:

List<Task<int>> tasks = new List<Task<int>>();
for (int i = 0; i < 10; i++)
{
    tasks.Add(Process(i));
}
Task.WaitAll(tasks.ToArray());

List<int> results = new List<int>();
foreach (var task in tasks)
{
    results.Add(task.Result);
}

Notar cómo al cambiar el tipo devuelto por Process() a Task<int>, también tenemos que cambiar el tipo de datos de la lista donde guardamos las tareas que se van ejecutando a List<Task<int>>, para poder tener acceso al resultado posteriomente mediante task.Result.

El resultado de la ejecución es el siguiente:

Process 0: 00:00:00.2077483
Process 1: 00:00:00.2076874
Process 3: 00:00:00.2074275
Process 2: 00:00:00.2057897
Process 7: 00:00:00.2097799
Process 6: 00:00:00.2101881
Process 5: 00:00:00.2103866
Process 4: 00:00:00.2109039
Process 9: 00:00:00.2004370
Process 8: 00:00:00.2006408

Result: 76,2,79,86,12,45,27,17,55,5
Completed: 00:00:00.6971794

En este ejemplo, hemos tenido que procesar todos los resultados a posteriori, una vez todos los procesos han finalizado la ejecución. Para este ejemplo sencillo, este segundo bucle foreach ha incrementado el tiempo en casi una décima, pasando de los 0,6s originales a casi 0,7s. Imaginemos un caso complejo, donde hubiera que analizar cientos o miles de resultados, y es posible que estuviéramos perdiendo gran parte del rendimiento conseguido con la paralelización del proceso.

Devolver el resultado ya procesado

Para no tener que recuperar los resultados de los procesos asíncronos en un bucle posterior, podemos hacer uso listas concurrentes que son thread-safe, como ConcurrentBag<T>. También existen versiones concurrentes de Dictionary, Queue y Stack. Con este tipo de datos, cada proceso podrá añadir su resultado directamente a la ConcurrentBag, de manera que al volver al hilo principal, ya no será necesario recorrer todas las tareas para obtener los resultados.

Para ello, añadimos la ConcurrentBag como parámetro a nuestro método Process() (ver archivo completo en Github):

private static async Task Process(int id, ConcurrentBag<int> cb)
{
    await Task.Run(() =>
    {
        Stopwatch timer = new Stopwatch();
        timer.Start();
        Random random = new Random();
        Thread.Sleep(200);

        int number = random.Next(1,100);
        cb.Add(number);

        Console.WriteLine($"Process {id}: {timer.Elapsed}");
    });
}

Con lo que ya no es necesario devolver un Task<int>, ni volver a procesar los resultados en el hilo principal, sino que podemos hacer uso directamente de los resultados que tenemos en la ConcurrentBag:

static async Task Main(string[] args)
{
    ConcurrentBag<int> cb = new ConcurrentBag<int>();
    Stopwatch timer = new Stopwatch();
    timer.Start();

    List<Task> tasks = new List<Task>();
    for (int i = 0; i < 10; i++)
    {
        tasks.Add(Process(i, cb));
    }
    Task.WaitAll(tasks.ToArray());

    Console.WriteLine();
    Console.WriteLine($"Result: {string.Join(",", cb)}");
    Console.WriteLine($"Completed: {timer.Elapsed}");
}

Volviendo a los resultados:

Process 1: 00:00:00.2029103
Process 2: 00:00:00.2028785
Process 0: 00:00:00.2029188
Process 3: 00:00:00.2028485
Process 5: 00:00:00.2007397
Process 7: 00:00:00.2007120
Process 6: 00:00:00.2007211
Process 4: 00:00:00.2008456
Process 9: 00:00:00.2001557
Process 8: 00:00:00.2007588

Result: 82,83,88,99,57,71,13,54,18,40
Completed: 00:00:00.6276547

de nuevo comprobamos que estamos más cerca de los 0,6 segundos que antes, al eliminar el post procesado innecesario de los resultados.

Conclusiones

Es posible ejecutar procesos en paralelo y obtener los resultados agrupados en un mismo objeto. Esto nos evitará un post procesado posterios de las tareas que añade tiempo innecesario de ejecución.
Existen tipos de datos thread-safe que podemos utilizar para almacenar resultados de tareas asíncronas, como ConcurrentBag, ConcurrentDictionary, ConcurrentQueue o ConcurrentStack. Aprender a usarlos nos abre nuevas opciones de mejora de nuestros procesos.

Improve the performance with asynchronous functions to run processes in parallel

2021-02-13T16:28:24Z

This post is part of a series of 3 articles about performace improvement with parallel programming:

1. Improve the performance with asynchronous functions to run processes in parallel (this article)
2. Make use of ConcurrentBag to store the results from asynchronous processes
3. Parallel programming in C# with class Parallel

Recently I was collaborating with a colleague at work because the running time of a process was far slower than expected. Reviewing the code, we identified that parts of the process could be done in parallel, with which the overall performance was improved by a 200%. In this post, I'll show some basic techniques to work with processes parallelization and will display the performance improvements that can be achieved.

Starting point

I am using a simple Console application in C# to showcase an elementary case, to see how we can improve the performance using parallel computing techiques. Sample source code can be found here: https://github.com/sgisbert/parallelization

The starting code is as follows (Ver en Github):

using System.Threading;
using System.Diagnostics;
using System;

namespace parallel
{
    class Program
    {
        static void Main(string[] args)
        {
            Stopwatch timer = new Stopwatch();
            timer.Start();

            for (int i = 0; i < 10; i++)
            {
                Process(i);
            }

            Console.WriteLine($"Completed: {timer.Elapsed}");
        }

        private static void Process(int id)
        {
            Stopwatch timer = new Stopwatch();
            timer.Start();
            Thread.Sleep(200);
            Console.WriteLine($"Process {id}: {timer.Elapsed}");
        }
    }
}

We have a process that takes 200ms to complete, and we call it 10 times in a row with a for loop. As expected, this code execution takes 2 seconds to complete, as each process has to wait for the previous one to finish before it is started:

Process 0: 00:00:00.2018134
Process 1: 00:00:00.2003564
Process 2: 00:00:00.2003647
Process 3: 00:00:00.2007673
Process 4: 00:00:00.2008702
Process 5: 00:00:00.2004851
Process 6: 00:00:00.2003682
Process 7: 00:00:00.2009726
Process 8: 00:00:00.2009657
Process 9: 00:00:00.2006482
Completed: 00:00:02.0362772

Converting the method into asynchronous

The goal is that these 10 processes could be executed asynchronously and parallelized, so they don't need to wait for the others to start. First step would be converting the Process() method into an asynchronous function, so we are doing the following changes (see full file on Github):

Change method signature:

private static async Task Process(int id)

Change the call:

await Process(i);

Change the Main method signature, so it is asynchronous as well:

static async Task Main(string[] args)

With these changes, we have our asynchronous method, but, ¿is the performance better now? If we run the application again, we are getting exactly the same results as at the beginning, this is, we still have the same problem.

This is due to the use of the await keyword, with which we are literally saying "wait until it finishes to continue". This is, we are executing an asynchronous method in a synchronous way, and this is not what we want.

Executing the process asynchronously

To run the process in an asynchronous way, we need to call the function without the await keyword. In this case, the method will return a Task object, instead of the function return value (althoug it was void in this sample, it could be any data type), and it will continue the execution without waiting for the process to complete. But still, we need to know when the overall execution of all the processes completes to continue with the main thread execution. For that, we are making the following changes (see full file on Github):

We declare a list of Task where we'll keep track of all the Task being created as the processes are started:

List<Task> tasks = new List<Task>();
for (int i = 0; i < 10; i++)
{
     tasks.Add(Process(i));
}
Task.WaitAll(tasks.ToArray());

We wait for all the tasks to complete with Task.WaitAll()

With these changes, we can run the program again and, surprise! We still have the same poor performance as at the start... What happened?

This is because the compiler needs the combination of both async/await keywords in a method to start a new execution thread. In this simple case, the Process() method is declared as async, but it is not making use of any await call, so the compiler will just treat it as a synchronous method. We will even be getting a warning from the compiler at editing time:

If as part of the method we would make use of any other asynchronous calls, like reading some data from a DB with EF Core, then we would get a new execution thread and the following step wouldn't be necessary.

Executing the processes in parallel

To make sure we are getting a new thread for each process, we are modifying the code like this (see full file on Github):

private static async Task Process(int id)
{
    await Task.Run(() =>
    {
        Stopwatch timer = new Stopwatch();
        timer.Start();
        Thread.Sleep(200);
        Console.WriteLine($"Process {id}: {timer.Elapsed}");
    });
}

This way, we use await to create a new thread with Task.Run().

When we run the application again, these are the results:

Process 2: 00:00:00.2016508
Process 3: 00:00:00.2010563
Process 1: 00:00:00.2016712
Process 0: 00:00:00.2053744
Process 7: 00:00:00.2008342
Process 6: 00:00:00.2008357
Process 5: 00:00:00.2008776
Process 4: 00:00:00.2009419
Process 8: 00:00:00.2091808
Process 9: 00:00:00.2091704
Completed: 00:00:00.6359204

Finally we can appreciate a notorious performance increase, as we moved from the original 2 seconds down to 0,6 seconds with the parallelized execution. Note as well that the execution order is randomly displayed, as the process do not rely any more on the starting order, but the time it takes to each one to complete.

Conclusions

Using this fairly simple parallelization technique, we can dramatically increase the performance in our applications.
We need to understand correctly how async/await works, because, as demostrated, simply converting a method into async and invoking it with await is not enough. You have to use Task.WaitAll() for this.
Generally speaking, when you find some processes that do not rely on each other, you may be able to parallelize them, as for example, make a DB query and loading some data from an XML file, or making a request to an external API.
Tip: if you see a bunch of await calls in a row, think if they can be parallelized.
If a process needs the outcome of another process as an input, these cannot be parallelized.
Not all cases can be parallelized, like for instance, using EF Core to access a DB will not allow to make two simultaneous requests using the same context.
However, working with the file system is a great candidate to process files in parallel and getting some performance gains.

In the following blog post I explain how to use Thread-safe data types to interact with them from different threads, as for instance, make some parallel calculations and get all together back into the same List.

Mejorar el rendimiento con funciones asíncronas para la ejecución de procesos en paralelo

2021-02-13T16:05:24Z

Disclaimer: los métodos y ejemplos de código de este artículo son fruto de mi propia investigación y aprendizaje autónomo, y en ningún caso están preparados para su utilización en código real de producción. El autor no se hace responsable del uso de estos ejemplos. Para más información sobre programación paralela y asíncrona y sus connotaciones, recomiendo acceder a la documentación oficial: https://docs.microsoft.com/es-es/dotnet/standard/parallel-processing-and-concurrency

Este post forma parte de una serie de 3 artículos sobre mejoras de rendimiento utilizando programación paralela:

1. Mejorar el rendimiento con funciones asíncronas para la ejecución de procesos en paralelo (Este artículo)
2. Utilizar ConcurrentBag para almacenar el resultado de métodos asíncronos
3. Programación paralela en C# con la clase Parallel

Recientemente tuve que colaborar con un compañero de trabajo porque la ejecución de un proceso era más lenta de lo esperado. Repasando el código, vimos que parte del proceso se podía realizar en paralelo, con lo que el rendimiento general mejoró en un 200%. En este post intento explicar algunas técnicas básicas para trabajar con paralelización de procesos y mostraré las mejoras de rendimiento que se pueden obtener.

Caso inicial

Vamos a utilizar una simple aplicación de consola C# para ilustrar un caso sencillo, y cómo vamos a mejorar su rendimiento utilizando técnicas de computación paralalela. El código fuente lo podéis encontrar aquí: https://github.com/sgisbert/parallelization

El código inicial será el siguiente (Ver en Github):

using System.Threading;
using System.Diagnostics;
using System;

namespace parallel
{
    class Program
    {
        static void Main(string[] args)
        {
            Stopwatch timer = new Stopwatch();
            timer.Start();

            for (int i = 0; i < 10; i++)
            {
                Process(i);
            }

            Console.WriteLine($"Completed: {timer.Elapsed}");
        }

        private static void Process(int id)
        {
            Stopwatch timer = new Stopwatch();
            timer.Start();
            Thread.Sleep(200);
            Console.WriteLine($"Process {id}: {timer.Elapsed}");
        }
    }
}

Tenemos un proceso que tarda 200ms en ejecutarse, y lo ejecutamos 10 veces, de forma secuencial con un bucle for. Como cabría esperar, la ejecución de este código tarda unos 2 segundos en completarse, ya que cada proceso tiene que esperar a que termine el anterior para iniciarse:

Process 0: 00:00:00.2018134
Process 1: 00:00:00.2003564
Process 2: 00:00:00.2003647
Process 3: 00:00:00.2007673
Process 4: 00:00:00.2008702
Process 5: 00:00:00.2004851
Process 6: 00:00:00.2003682
Process 7: 00:00:00.2009726
Process 8: 00:00:00.2009657
Process 9: 00:00:00.2006482
Completed: 00:00:02.0362772

Convertir el método en asíncrono

El objetivo es que estos 10 procesos se puedan lanzar de manera asíncrona y en paralelo, de manera que no tengan que esperarse unos a otros para arrancar. El primer paso será convertir el método Process() en una función asíncrona, por lo que hacemos los siguientes cambios (ver archivo completo en Github):

Cambiar la signatura del método:

private static async Task Process(int id)

Cambiar la llamada:

await Process(i);

Cambiar la signatura del método Main para que también sea asíncrono:

static async Task Main(string[] args)

Con esto ya tenemos nuestro método asíncrono, pero, ¿ha mejorado el rendimiento? Si lo volvemos a ejecutar, obtenemos exactamente los mismos valores que en la ejecución anterior, es decir, seguimos con el mismo problema.

Esto es debido a que estamos llamando al proceso con el modificador await, con lo que literalmente le estamos diciendo "espera a que termine para continuar". Es decir, estamos llamando a un método asíncrono de manera síncrona, y no es lo que queremos.

Ejecutar el proceso de manera asíncrona

Para ejecutar el proceso de manera asíncrona, debemos llamar al método sin el modificador await. En este caso, la función devuelve un objeto Task en lugar del resultado de la misma (aunque era void en este caso, pero podría devolver cualquier tipo de datos), y va a seguir la ejecución sin esperar a que ésta finalice. Pero igualmente necesitamos saber cuándo termina la ejecución de todos los procesos para seguir con la ejecución principal. Para ello, hacemos los siguientes cambios (ver archivo completo en Github):

Creamos una lista de Task donde iremos guardando las Task que se vayan creando conforme vamos lanzando los procesos

List<Task> tasks = new List<Task>();
for (int i = 0; i < 10; i++)
{
     tasks.Add(Process(i));
}
Task.WaitAll(tasks.ToArray());

Esperamos a que todas las tareas terminen mediante Task.WaitAll()

Con estos cambios, volvemos a lanzar el programa y, ¡sorpresa! Seguimos teniendo el mismo rendimiento que al principio. ¿Qué ha pasado?

Esto es debido a que el compilador necesita de la combinación de async/await en un método para lanzar un nuevo hilo de ejecución. En este caso sencillo, la función Process() está declarada como async, pero no hace ninguna llamada await, por lo que el compilador la va a ejecutar de manera síncrona. El propio compilador nos avisará con un warning:

Si dentro de este método hiciéramos uso de otras llamadas asíncronas, como leer registros de una BD con EF Core, por ejemplo, entonces sí que tendríamos un nuevo hilo de ejecución y el paso siguiente no sería necesario.

Ejecutar el proceso en paralelo

Para asegurarnos de que el proceso se inicia en un hilo diferente en cada caso, modificamos el método de la siguiente manera (ver archivo completo en Github):

private static async Task Process(int id)
{
    await Task.Run(() =>
    {
        Stopwatch timer = new Stopwatch();
        timer.Start();
        Thread.Sleep(200);
        Console.WriteLine($"Process {id}: {timer.Elapsed}");
    });
}

De esta manera, utilizamos await pero lanzando un nuevo hilo con Task.Run().

Cuando ejecutamos el proceso principal, estos son los resultados:

Process 2: 00:00:00.2016508
Process 3: 00:00:00.2010563
Process 1: 00:00:00.2016712
Process 0: 00:00:00.2053744
Process 7: 00:00:00.2008342
Process 6: 00:00:00.2008357
Process 5: 00:00:00.2008776
Process 4: 00:00:00.2009419
Process 8: 00:00:00.2091808
Process 9: 00:00:00.2091704
Completed: 00:00:00.6359204

Finalmente sí podemos apreciar una mejora notable, ya que hemos pasado de los 2 segundos iniciales a 0,6 segundos con la ejecución en paralelo. Notar igualmente que el orden en el que termina cada proceso es aleatorio, ya que ya no dependen del orden en el que se ejecutan, sino del tiempo que tarda cada uno de ellos.

Conclusiones

Utilizando esta sencilla técnica de paralelización podemos aumentar drásticamente el rendimiento de nuestras aplicaciones.
Hay que saber aplicarlo correctamente, porque simplemente convirtiendo un método en async y llamarlo con await no es suficiente, como hemos visto en el ejemplo. Usamos Task.WaitAll() para esto.
En general, cuando tengamos procesos que no dependan unos de otros, podremos paralelizarlos, como por ejemplo, hacer una consulta a BD mientras cargamos unos textos de un archivo XML o llamamos a un servicio de una API externa.
Si ves unas cuantas llamadas seguidas con await, piensa si se pueden paralelizar.
Si un proceso dependo de otro, no se podrá paralelizar.
No en todos los casos se puede paralelizar, por ejemplo, si usamos EF Core para el acceso a BD, no podemos tener dos llamadas simultáneas con el mismo contexto.
En cambio, si trabajamos con archivos, podemos procesarlos de manera paralela y mejorar así el rendimiento.

En la siguiente entrada del blog comentamos cómo usar tipos de datos Thread-Safe para interactuar con ellos desde diferentes hilos, como por ejemplo, realizar procesos en paralelo que nos devuelvan el resultado en una misma Lista.

Validación de API requests y JSON Schemas con Postman

2021-01-30T17:29:22Z

Postman es una herramienta muy útil para probar las peticiones a APIs, tanto si las estamos desarrollando nosotros, como si son de otro proveedor, y poder así testear y comprobar los datos que se reciben en cada llamada. En este post, abordaré cómo incluir tests de validación para comprobar que las llamadas se reciben correctamente y que además, los datos que recibimos cumplen con un determinado schema JSON predefinido.

Este post forma parte de la serie de artículos sobre Postman, que empezamos con la automatización de la autenticación de APIs.

Comprobación del resultado de la llamada

El primer test y el más sencillo que podemos incorporar es validar que la llamada se ha realizado correctamente, y hemos recibido un Response 200 OK, o cualquier otro que estemos esperando. Para ello, la manera más sencilla es incluir este test a nivel de Collection, para que así todas las peticiones incluidas en la misma hereden este test.

Para ello, editamos la colección y en la pestaña "Tests", incluimos el siguiente script:

pm.test("Status code is OK", function () {
    pm.expect(pm.response.code).to.be.oneOf([200, 201, 204, 207])
});

En la lista de códigos de respuesta podemos incluir todos los que necesitemos. Una vez configurado, si ejecutamos cualquier petición, podemos ver en la pestaña "Tests" de la respuesta el resultado del mismo:

Validación del schema JSON de la respuesta

El lenguage de scripting de Postman es muy versátil, y nos permite ir más allá de una simple comprobación del estado de la respuesta, y podemos incluir validaciones más complejas, como por ejemplo, comprobar que el contenido de la respuesta en JSON cumple con el schema predefinido que debe devolver dicha petición.

Para poder ejecutar esta validación, volvemos a la pestaña "Tests" de la Collection, y añadimos el siguiente script, a continuación del script anterior:

try 
{
    var schema = pm.variables.get("schema");

    if(schema)
    {
        const jsonData = pm.response.json();
        if(jsonData)
        {
            //const dateTimeRegex = new RegExp('^(-?(?:[1-9][0-9]*)?[0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(.[0-9]+)?$');
            var Ajv = require('ajv'),
            ajv = new Ajv({logger: console, allErrors: true});
            //ajv.addFormat('date-time', {
            //    validate: (dateTimeString) => dateTimeRegex.test(dateTimeString)
            //});
        
            pm.test('Schema is valid', function() {
                var validate = ajv.validate(schema, jsonData);
                console.log(ajv.errors);
                pm.expect(validate, JSON.stringify(ajv.errors)).to.be.true;
            });
        }
    }
}
catch(e){
    console.log(e);
}

Este script obtendrá el schema de una variable "schema", que luego definiremos, y validará el contenido de la respuesta de la petición contra dicho schema, utilizando la librería "Ajv". Como añadido, he dejado comentado cómo definir un formato de fecha específico, para validaciones que requieran un formato de fecha diferente.

El siguiente paso será obtener el schema que debe devolver la petición. Si disponemos del detalle del API que estamos consumiendo en en servicios como Apiary o Swagger, estos mismos servicios ya nos proporcionan el detalle del schema en su definición de cada petición. Si no disponemos de ellos, pero tenemos un objeto JSON válido, podemos utilizar herramientas online como Quicktype, para generar nuestro schema. En este ejemplo, podéis ver el schema generado para un json del API de Zendesk:

Una vez que ya tenemos el schema, volvemos a Postman y seleccionamos la petición sobre la cual queremos validar su schema, y editamos la pestaña "Pre-request Script", donde incluimos el siguiente script (usando el schema obtenido con antelación):

var schema = {
    "$schema": "http://json-schema.org/draft-06/schema#",
    "$ref": "#/definitions/ZendeskJobResult",
    "definitions": {
        "ZendeskJobResult": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "action": { "type": "string" },
                "id": { "type": "integer" },
                "status": { "type": "string" },
                "success": { "type": "boolean" }
            },
            "required": ["action", "id", "status", "success" ],
            "title": "ZendeskJobResult"
        }
    }
};

pm.variables.set("schema", schema);

Por defecto, es posible que nos defina todos los campos como "Required", por lo que tendremos que validar manualmente si es correcto, y modificarlo según nuestras necesidades. Estamos añadiendo el schema a una variable local, que luego guardamos como variable de ejecución.

Este proceso tendremos que hacerlo para cada una de las peticiones que queramos validar, ya que por norma general, el schema de los datos devueltos por cada petición será diferente, pero sólo tenemos que definir el schema, ya que el script de validación lo hemos definido a nivel de Collection.

El funcionamiento es el siguiente:

Antes de iniciarse la petición, el script de "Pre-request Script" de la petición se ejecuta, y define el valor de la variable "schema"
Después de ejecutarse la petición, el script de "Tests" de la Collection se ejecuta, y utiliza la variable definida por la petición para validar la misma

Como resultado, podemos ver que la pestaña de Tests de la respuesta se ha ampliado con un segundo test:

En el caso de que no valide el schema, nos indicará cuál ha sido la propiedad que no cumple y el motivo:

En este caso, podemos ver que falta la propiedad "serviceList", que estaba marcada como requerida.

Ejecución de tests masivos

Una vez tenemos definidos estos tests de validación, podemos hacer uso de otra de las herramientas que incluye Postman para ejecutar validación por lotes de todas o un conjunto de las peticiones definidas en una Collection. Para ello, abrimos la herramienta Runner:

Elegimos la Collection a ejecutar, o la carpeta que queramos lanzar, incluso qué peticiones incluimos en la ejecución, el Environment sobre el que lo ejecutamos, así como el número de veces que se va a lanzar, el delay entre cada petición y algunos settings adicionales. Runner se encargará de lanzar todas las peticiones por nosotros, y mostrarnos un resumen de resultados de las mismas:

De esta manera, podemos lanzar de una forma sencilla todas nuestras peticiones y comprobar que todo sigue funcionando correctamente después de, por ejemplo, un despliegue a producción.

Validating API Requests and JSON schemas with Postman

2021-01-30T17:31:31Z

You can find the Spanish version of this post here.

Postman is a useful tool to test API requests, whether we are developing our own APIs, as well as we are using a third party provider APIs, so that we can check all the data received on each request. In this post, I will explain how to include validation tests along with each request, to check the calls are succesful and also that the json data received meets the expected JSON schema agreed.

This post is part of a series about Postman, started with Automatic API authentication.

Check request result

The first and simpler test that we can include is to validate the request has succeded, and we got the Response 200 OK, or any other response code we may be expecting. To do so, the easiest way is to include the test at the Collection level, so that all the requests underneath will inherit this validation.

So you can edit the Collection, select the "Tests" tab, and include the following script:

pm.test("Status code is OK", function () {
    pm.expect(pm.response.code).to.be.oneOf([200, 201, 204, 207])
});

You can include any other response codes you might be expecting from your requests as well.

Once set up, on any request execution, you should see the test result in the response "Tests" tab:

Response JSON schema validation

Postman scripting is quite a powerful asset, so you can go beyond a simple response code validation and include more complex validations, like checking that the response JSON meets a determined schema.

In order to execute such validation, back to the "Tests" tab in the Collection to include the following script, right after the previous script we added in the previous step:

try 
{
    var schema = pm.variables.get("schema");

    if(schema)
    {
        const jsonData = pm.response.json();
        if(jsonData)
        {
            //const dateTimeRegex = new RegExp('^(-?(?:[1-9][0-9]*)?[0-9]{4})-(1[0-2]|0[1-9])-(3[01]|0[1-9]|[12][0-9])T(2[0-3]|[01][0-9]):([0-5][0-9]):([0-5][0-9])(.[0-9]+)?$');
            var Ajv = require('ajv'),
            ajv = new Ajv({logger: console, allErrors: true});
            //ajv.addFormat('date-time', {
            //    validate: (dateTimeString) => dateTimeRegex.test(dateTimeString)
            //});
        
            pm.test('Schema is valid', function() {
                var validate = ajv.validate(schema, jsonData);
                console.log(ajv.errors);
                pm.expect(validate, JSON.stringify(ajv.errors)).to.be.true;
            });
        }
    }
}
catch(e){
    console.log(e);
}

This script will get the schema from the "schema" variable, that we'll set up later, and will validate the response content against it, using the "Ajv" library. As an add-on, I left commented out how to include a specific date formatting validation rule, in cases where you might need custom formats for some data types.

Next step will be to get the schema itself that we are expecting the response to return. If you have access to the API service details, with tools like Apiary or Swagger, you can get the schema details from them. If not, but you have a valid JSON object, you can use online tools like Quicktype to generate your own schema. In the following screenshot, you can see the schema generated with a JSON from the Zendesk API:

Once you got the schema, back to Postman, select the request you want to be validated, and edit the "Pre-request Script" tab, where you should add the following script (using the schema from the step before):

var schema = {
    "$schema": "http://json-schema.org/draft-06/schema#",
    "$ref": "#/definitions/ZendeskJobResult",
    "definitions": {
        "ZendeskJobResult": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "action": { "type": "string" },
                "id": { "type": "integer" },
                "status": { "type": "string" },
                "success": { "type": "boolean" }
            },
            "required": ["action", "id", "status", "success" ],
            "title": "ZendeskJobResult"
        }
    }
};

pm.variables.set("schema", schema);

By default, it is possible that all the properties may be included in the "required" array, so you will need to manually check if that fits your needs. You are adding the schema to a local variable, and then storing it as a runtime variable.

You need to do this process for every single request you want to validate, as normally the response data schema will be different on every request, but this is the only step you need to do, as the validation script itself is shared across the Collection.

It works in the following way:

Before the request is sent, the "Pre-request Script" is executed and the "schema" variable is stored.
After the request is executed, the script in Collection "Tests" tab is executed, and will use the variable set up by the request to validate the response data.

As a result, you should see in the response Tests tab a second test included:

In the event that the data is not valid, you should see the wrong property and the reason why the schema was not met:

In this case, you can see the "serviceList" property is missing, but it was defined as "required".

Tests execution in batches

Once validation tests are defined, we can make use of another tool included with Postman to run a batch execution of all or a selected subset of requests defined in a Collection. To do so, you can use Runner:

You should select the Collection to execute, or the folder, or even the specific requests you want to include in the bath; then the Environment used, and the number of executions, the delay between each request, and some other additional settings. Runner will execute all the requests for us, and will present us with a report on finalization:

This way, we can easily run all our requests and check that everything is still fine after a deployment into Production, for example.