A Diagnosis Of Parallel.Foreach

So, let’s see our code,

We will create a new class “ApiParallelOperations” in which we will add a private method to call the API and it will not be the benchmark method.

public async Task < int > GetData(HttpClient http) {
    List < UserModel > users = new List < UserModel > ();
    string url = "https://localhost:44363/api/users";
    var res = await http.GetAsync(url);
    if (res.IsSuccessStatusCode) {
        var stringResponse = await res.Content.ReadAsStringAsync();
        users = JsonConvert.DeserializeObject < List < UserModel >> (stringResponse);
    }
    return users.Count;
}

Note
API is called in the above code is running on my pc.

Now let’s see our benchmark methods.

[Benchmark]
public async Task < List < int >> NormalForApi() {
    var list = new List < int > ();
    var tasks = Enumerable.Range(0, 1000).Select(_ => new Func < Task < int >> (() => GetData(httpClient))).ToList();
    foreach(var item in tasks) {
        list.Add(await item());
    }
    return list;
}

In the above code, we have just created a list of tasks (1000) and by wrapping the GetData method in new Func we make sure that it will not be called immediately and then below it inside the foreach(for) when we await the method while adding it to the list it gets called.

Now our parallel method will be,

[Benchmark]
public List < int > ParallelApi() {
    var list = new List < int > ();
    var tasks = Enumerable.Range(0, 1000).Select(_ => new Func < int > (() => GetData(httpClient).GetAwaiter().GetResult())).ToList();
    Parallel.For(0, tasks.Count, i => {
        list.Add(tasks[i]());
    });
    return list;
}

In here as well we are doing pretty much the same thing, the only difference is we are using GetAwaiter().GetResult() while creating tasks list because Parallel.For doesn’t allow async-await keyword.

So, our entire class looks something like this,

Now let’s run the code and see the results.

Now here as we can see Parallel. For is clearly faster in this case.

Note
Time performance will differ on each user’s system because API was running on my local system and spiking the resources of my system.

In a real-world scenario, especially in a microservices environment, your service will most likely be running in a Kubernetes cluster. So for this scenario, there is recommended change below,

[Benchmark]
public List < int > ParallelApiWithMaxDegreeOfParallelism() {
    var list = new List < int > ();
    var tasks = Enumerable.Range(0, 1000).Select(_ => new Func < int > (() => GetData(httpClient).GetAwaiter().GetResult())).ToList();
    Parallel.For(0, tasks.Count, new ParallelOptions() {
        MaxDegreeOfParallelism = 4
    }, i => {
        list.Add(tasks[i]());
    });
    return list;
}

In the above method, we have limited the max number of parallelism your code can run.

This is basically to make sure that your code doesn’t bottleneck the cluster or the system where your code is running.

Now let’s run the code and see the difference

So as you can see the timings make sense with what we have coded.

NormalForApi uses the traditional for loop to call the http service and it takes the longest

ParallelApi uses the Parallel. For loop with unlimited number of parallelism and executes the same amount of http service calls in much less time.

ParallelApiWithMaxDegreeOfParallelism uses the Parallel. For loop with the maximum number of parallelism set as 4 and as you can see the time to execute the same amount of services is slightly more than ParallelApi method but it is still better performing than traditional for loop.

Summary

In today’s article, we have seen the uses of Parallel. For and compared its performance with traditional for loop in different scenarios.

If you wish to see the code, please click here!