Slow Response in .NET 6

I’m having an issue upgrading the project to .NET 6 and version 18.0.0.

In .NET 5, version 17.0.1 the API Gateway works great, but I 've tried several times to upgrade to .NET 6 and Ocelot version 18.0.0 and the response become extremely slow. They queue for minutes or just hang and the app gets no response. The first time this happened, I just upgraded the project to .NET 6, but stayed with Ocelot 17, for which I could say it might be an issue with .NET 6.

I have followed the latest documentation for .NET 6 and keep getting the same results.

This is my Program file:

using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.Hosting;

namespace ApiGateway
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureAppConfiguration((hostingContext, configuration) =>
                {
                    configuration.Sources.Clear();

                    configuration
                       .AddJsonFile("appsettings.json", true, true)
                       .AddJsonFile("ocelot.json", false, true)
                       .AddEnvironmentVariables();
                })
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

My Startup file:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Ocelot.DependencyInjection;
using Ocelot.Middleware;

namespace ApiGateway
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddSingleton(x => Configuration);

            services.AddCors(options =>
            {
                options.AddDefaultPolicy(
                    builder =>
                    {
                        if (Configuration.GetValue<string>("AllowedHosts") == "*")
                            builder.AllowAnyOrigin();
                        else
                            builder.WithOrigins(Configuration.GetValue<string>("AllowedHosts"));

                        builder
                        .AllowAnyMethod()
                        .AllowAnyHeader();
                    });
            });

            services.AddOcelot(Configuration);
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseHttpsRedirection();
            app.UseRouting();
            app.UseCors();
            app.UseOcelot().Wait();
        }
    }
}

Any help on this would be appreciated.

• Version: 18.0.0
• Platform: .NET 6

[ToniSoriano]

In .net 6 these are the times:

however in .net 5 the times are much better.

This test has been done with the version 17.0.1. With the version 18.0.0 the same results are obtained.

[gramirez897]

I have been doing some tests for this issue and I’ve almost arrived at the conclusion that my issue is caused by IIS Express.

I tried following this tutorial for the latest Ocelot implementation and when I created a new VS ASP.Net Core 7 Empty project it runs in the a debug console instead of IIS Express. This way the gateway works perfectly.

https://www.youtube.com/watch?v=k4l3Ptd4yjw

After that I tried changing the launchSettings.json file so that the application would run with IIS Express instead and the problem started again. The requests get queued for at least 2 minutes when upgrading from .net 5 to 6 or 7.

I still can’t explain why it would behave this way with IIS Express only though.