On Mon, Sep 28, 2020 at 4:19 AM Nicholas Bunn <[email protected]> wrote:
> That's helped to clear it up quite a bit for me. Is there a particular > reason to avoid sending each RPC call in its own thread? > Not much from gRPC's perspective. Sync vs async APIs can behave a bit differently, depending on how the threading works out, so sometimes one will be a bit faster than the other (although maybe with a latency vs throughput tradeoff). But for most users the difference is probably in the noise. The main day-to-day reason to not send each RPC on its own thread is mainly the memory cost of the thread itself. At high scale and high performance, other things can come into play, but most application's don't live at that level of scale. If interested, you can look into the "C10k problem" that originated in 1999, servicing 10k connections/clients at once. But you have to realize a lot of information will be out-of-date, as the precise details change year-to-year. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oP%2B2En3c3HGVY3f1Pp4rYSjnfjL4vo2-6Uc60uEUYjgEg%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
