cyanfish / grpc-dotnet-namedpipes

Named pipe transport for gRPC in C#/.NET
Apache License 2.0
190 stars 48 forks source link

Support for larger thread pool #43

Closed pockets3407 closed 1 year ago

pockets3407 commented 1 year ago

Currently, the thread pool is set to 4 inside ServerStreamPool. Is there a way this can be a set to a higher number through NamedPipeServerOptions that is defaulted to 4?

cyanfish commented 1 year ago

I could potentially add an option for that, though I'm curious as to your use case. Do you have a very high QPS? The threads are only used to initiate the connections, not run the actual methods.

pockets3407 commented 1 year ago

Yes, I have some calculations that are running parallel to each other and send the result using named pipes. It also allows me to use streaming calls without impacting performance.

cyanfish commented 1 year ago

I just want to make sure this would actually help. You should be able to have hundreds of streaming calls operating in parallel no problem - the only limit is the Windows limit for simultaneous named pipe connections, which I believe is 256. If there is a performance issue under that limit, it would likely be with the Task scheduler, not the listener thread pool. If the listener thread pool is exhausted you'll get connection errors, not slowdowns.

cyanfish commented 1 year ago

I don't know exactly what you're doing, but inferring from that you're running calculations that are presumably CPU-intensive and result in long-running tasks that would be limited in parallelism by the .NET Task scheduler, you may want to spawn a separate thread to run your calculations, e.g.

public override async Task Calculate(CalcReq req, IServerStreamWriter<CalcResults> results, ServerCallContext context)
{
    var tcs = new TaskCompletionSource();
    var thread = new Thread(() =>
    {
        DoSomeWork();
        results.WriteAsync(new CalcResults());
        tcs.SetResult();
    });
    thread.Start();
    await tcs.Task;
}
pockets3407 commented 1 year ago

After further investigation, the .NET Task Scheduler seems to be affecting performance more than expected when these calculations are run. I will close this issue for now and reopen if I still find an issue after resolving my issues with the .NET Task Scheduler.