In this post I’m going to be writing about using async queries using the data from Ways to load a file to postgres. I worked with async database calls there as well, but this time I wanted to see what effect it would have on a web service. I took a similar approach to what I did in Why async is important to a web service. There is an API and a client, the client calls either the sync or async API and reports timings and error counts. The API is simple, one endpoint to get all the keys, then two APIs to get details about each anime, sync and async. The code for this is simple.

My site also has a new URL. It is now https://blog.james-dalton.net. If you bookmarked http://james-dalton.net you will want to update your bookmark. For now, it redirects here. I changed the URL so I could use this domain for more than just this blog. Not that I have any plans to do that yet, but at least now I can. I also pick up HTTPS for free from GitHub Pages.

To write a post about async queries I first need to load some data to Postgres. The data came form https://www.kaggle.com/CooperUnion/anime-recommendations-database. I wanted to use real data and I’m an anime fan, so it was the perfect fit. It’s a CSV file so there is no normalization. That’s ok. If there was this would be a short post. I decided to try several ways of loading the data to see which would be fastest. To be honest, I already knew which one was going to win I wanted to see how close I could get using other methods without over engineering it or getting cute with the code. I ended up going there anyway, but the method that came in a close second was a simple solution.

I have never liked writing this in C#. It feels out of place.

while (reader.read())
{
    //process row
}

This is the way I think it should look.

foreach(var row in reader.read())
{
    //process row
}

At a high level, ASP.Net uses a thread pool to process requests. How many threads is based on a number of factors including configuration and work load. New threads will be added to the pool as needed but there is a startup penalty. According to ASP.NET Thread Usage on IIS 7.5, IIS 7.0 and IIS 6.0, it only adds 2 per second. If there is a sudden burst of activity, it will take time to spin up new threads. One way to avoid the penalty is to make the best use of the threads available.