gRPC .NET C# server request handling

28 views
Skip to first unread message

Martin Scholz

unread,
Mar 11, 2020, 4:30:57 PM3/11/20
to grpc.io
Is there any documentation how gRPC on server side with .NET or C# is handling multiple request under the hood. Does every request consume a thread until it's finished. Or can another request use the this thread when it is asnyc? And what it is the number of concurrent requests/threads.

Christopher Warrington - MSFT

unread,
Mar 11, 2020, 5:29:31 PM3/11/20
to grpc.io
On Wednesday, March 11, 2020 at 1:30:57 PM UTC-7, Martin Scholz wrote:
 
> Is there any documentation how gRPC on server side with .NET or C# is
> handling multiple request under the hood.

The closest that I know of is the GrpcEnvironment API documentation [1].


> Does every request consume a thread until it's finished. Or can another
> request use the this thread when it is asnyc?

gRPC C# uses its own thread-pool [2] to handle gRPC operations like reading
from and writing to the network, monitoring for timeouts, and cancelling
requests. After it has figured out which user code to invoke, by default, it
uses the .NET thread pool to run that code. The guards against buggy/slow
user code blocking gRPC from making forward progress.


> And what it is the number of concurrent requests/threads.

Unless customized by calling one of the methods on GrpcEnvironment [3], the
larger of 4 and Environment.ProcessorCount / 2 threads are used to poll 4
completion queues. (A completion queue is the underlying data structure that
gRPC uses to manage its operations.)

[1]: https://grpc.github.io/grpc/csharp/api/Grpc.Core.GrpcEnvironment.html
[2]: https://github.com/grpc/grpc/blob/c1349090872753dcafbb03789bb3417f6d4b2849/src/csharp/Grpc.Core/Internal/GrpcThreadPool.cs
[3]: https://github.com/grpc/grpc/blob/c1349090872753dcafbb03789bb3417f6d4b2849/src/csharp/Grpc.Core/GrpcEnvironment.cs#L198-L249

--
Christopher Warrington
Microsoft Corp.

Martin Scholz

unread,
Mar 12, 2020, 6:51:32 AM3/12/20
to grpc.io
Thx for the explanation. But wWhat about having 1000 or 10000 bi-directional client streams on the server which may have long waiting async calls to the backend. Is there a need to customize the thread size?

Jan Tattermusch

unread,
Mar 17, 2020, 9:13:04 AM3/17/20
to Martin Scholz, grpc.io
No need to use more threads. The threads will be shared by multiple requests just fine (same idea as with any other thread pool).
If you have a high number of concurrent class (thousands), you might need to adjust the number of allowed concurrent calls on the server though: https://github.com/grpc/grpc/blob/7be8cef10a4ea02b682a44c92f54a645bb9a61d8/src/csharp/Grpc.Core/Server.cs#L125


--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/9ec5e880-85a0-43f4-99ea-8a01c5baf754%40googlegroups.com.


--

Jan Tattermusch

Software Engineer


Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

Reply all
Reply to author
Forward
0 new messages