Thanks for your tests! I have read through your tests and learn a lot of things beyond documentation! Thanks! I am implementing a pub/sub service and have some problems in threading models used for subscribers service in server side. May I discuss my question with you for that? [email protected]
On Wednesday, February 17, 2016 at 8:14:53 AM UTC+8, Vijay Pai wrote: > > Hello, > Yes, you need to provide your own thread pool for the async model if you > want multithreaded RPC processing of RPCs. The most straightforward > example, IMO, is in test/cpp/thread_stress_test.cc . > > On Friday, February 12, 2016 at 2:14:49 PM UTC-8, [email protected] wrote: >> >> I suppose what you said is about sync server only. What about Async >> server threading model? Do we need to have our own thread pool when we use >> Async server? If so, is there an example we can follow? >> > > Yes, you need to provide your own thread pool for the async model if you > want multithreaded processing of RPCs and/or responses. The most > straightforward example, IMO, is in test/cpp/end2end/thread_stress_test.cc > . There are more complex examples in test/cpp/qps/*async.cc as well. > > The helloworld greeter_async_server example is single threaded, and when I >> added multi-threads to handle cq, it doesn't work some times (hitting >> server.cc:442 assertion error with GRPC_CALL_ERROR_TOO_MANY_OPERATIONS). >> > > I'm going to followup on your other message at > https://groups.google.com/forum/#!topic/grpc-io/yCzzroDbPa0 as I think > you're describing your issue as a case of mixing sync and async. > > >> >> On Wednesday, February 10, 2016 at 11:24:18 PM UTC-8, Vijay Pai wrote: >>> >>> Hi there, >>> The sync server threading model is implemented (currently) in various >>> files in src/cpp/server . The essential idea is that there are many ways to >>> implement the abstract base class ThreadPoolInterface. This is internal to >>> the gRPC C++ implementation and not directly accessible by the user-level >>> API. The implementation in current use is class DynamicThreadPool . This >>> thread pool reacts to new work (RPCs to service) by keeping a certain >>> number of threads in reserve (based on the number of cores), spawning new >>> threads if the currently created threads are all in use, and freeing >>> threads once the work is done and we have too many threads lying around (> >>> the reserved count). >>> >>> These are the basic ideas, but the details of the thread-pool >>> implementation may change as versions of gRPC C++ evolve. >>> >>> Best regards, >>> Vijay >>> >>> On Wed, Feb 10, 2016 at 11:11 PM Poojitha A <[email protected]> wrote: >>> >>>> Hi Craig, >>>> >>>> When you say "*The C++ server has two threading models available: sync >>>> and async. Most users will want to use the sync model: the server will >>>> have >>>> an (internal) threadpool that manages multiplexing requests onto some >>>> number of threads (reusing threads between requests). "* >>>> >>>> Could you please be more specific as in how does the multiplexing >>>> happen and how the server spaws the threads? >>>> >>>> Any details on this please >>>> >>>> On Tue, Feb 2, 2016 at 5:17 PM, 'Craig Tiller' via grpc.io < >>>> [email protected]> wrote: >>>> >>>>> My expectation is that C# should be seeing performance similar to >>>>> Java. We've not done any serious benchmarking yet, but we expect to soon >>>>> - >>>>> and when that happens I expect there'll need to be some tuning made to >>>>> the >>>>> stack. But C# performance is something we care about. >>>>> >>>>> On Tue, Feb 2, 2016 at 5:14 PM Luke Mauldin <[email protected]> >>>>> wrote: >>>>> >>>>>> Craig, >>>>>> >>>>>> Thank you very much for the answer and for providing a roadmap of >>>>>> what to expect in upcoming releases. Have there been any medium-scale >>>>>> concurrent tests done on the C# server? I am concerned that the Grpc >>>>>> C++ >>>>>> server might receive more attention, have greater stability, and offer >>>>>> substantially greater performance than the C# server since Google has >>>>>> preferred C++ to C# in the past. For Grpc, is C#'s server >>>>>> implementation >>>>>> considered "first class" as compared to C++, Java, etc...? >>>>>> >>>>>> Luke >>>>>> >>>>>> On Tue, Feb 2, 2016 at 6:50 PM Craig Tiller <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hey, >>>>>>> >>>>>>> Great question! >>>>>>> >>>>>>> The C++ server has two threading models available: sync and async. >>>>>>> Most users will want to use the sync model: the server will have an >>>>>>> (internal) threadpool that manages multiplexing requests onto some >>>>>>> number >>>>>>> of threads (reusing threads between requests). The async model allows >>>>>>> you >>>>>>> to bring your own threading model, but is a little trickier to use - in >>>>>>> that mode you request new calls when your server is ready for them, and >>>>>>> block in completion queues while there is no work to do. By arranging >>>>>>> when >>>>>>> you block on the completion queues, and on which completion queues you >>>>>>> make >>>>>>> requests, you can arrange a wide variety of threading models. >>>>>>> >>>>>>> We're working on exposing some knobs to control the behavior of the >>>>>>> synchronous thread pool. I expect to start seeing those changes hit the >>>>>>> codebase in the next 4-6 weeks, depending on where our priorities land. >>>>>>> >>>>>>> The C# server is similar to the synchronous mode of C++, mixed with >>>>>>> C#'s excellent async capabilities so that a request doesn't always take >>>>>>> up >>>>>>> a thread if there's no processing on it. >>>>>>> >>>>>>> Hope this helps, >>>>>>> Craig >>>>>>> >>>>>>> On Thursday, January 28, 2016 at 6:13:51 AM UTC-8, >>>>>>> [email protected] wrote: >>>>>>>> >>>>>>>> What is the GRPC server threading model? For example, if I write a >>>>>>>> GRPC C++ server, will GRPC automatically spawn multiple threads (or >>>>>>>> use an >>>>>>>> eventing model) to handle multiple simultaneous client requests? Are >>>>>>>> there >>>>>>>> any configuration parameters I can modify that will impact the number >>>>>>>> of >>>>>>>> supported simultaneous client connections? >>>>>>>> Also, are there any differences in the GRPC server threading model >>>>>>>> used in a C++ server vs a Csharp server? >>>>>>>> >>>>>>>> Luke >>>>>>>> >>>>>>> -- >>>>> 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 post to this group, send email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/grpc-io/CAAvp3oNpg%2ByVCdAJFfcg8s_gUvotdPB4nzV0H8%2BA87wkPjkVzw%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/grpc-io/CAAvp3oNpg%2ByVCdAJFfcg8s_gUvotdPB4nzV0H8%2BA87wkPjkVzw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> 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 post to this group, send email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/grpc-io/CAE-QhELXVwEAtK%2BiM5Yywx-uk6vC5pjN5Ow1tMWxU2KxMrkZ2g%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/CAE-QhELXVwEAtK%2BiM5Yywx-uk6vC5pjN5Ow1tMWxU2KxMrkZ2g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/61dbf15d-2786-4745-a0dc-1dc4b000a267%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
