Thank you for your answer~ 在 2017年4月5日星期三 UTC+8下午8:51:32，Craig Tiller写道： > > One of the huge advantages is that you can isolate work, so that different > threads don't interfere with each other (this is huge for performance). > > On Wed, Apr 5, 2017, 1:36 AM <201...@gmail.com <javascript:>> wrote: > >> hi， >> why is async server thread model not like sync server thread model that >> can use threadpool? what is the benefit of let user provide thread model? >> >> thanks~ >> >> 在 2016年2月17日星期三 UTC+8上午8:14:53，Vijay Pai写道： >> >>> 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, douy...@gmail.com >>> 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 <pooji...@gmail.com> >>>>> 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 < >>>>>> grp...@googlegroups.com> 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 <lukem...@gmail.com> >>>>>>> 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 <cti...@google.com> >>>>>>>> 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, >>>>>>>>> lukem...@gmail.com 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 grpc-io+u...@googlegroups.com. >>>>>>> To post to this group, send email to grp...@googlegroups.com. >>>>>>> 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 grpc-io+u...@googlegroups.com. >>>>>> To post to this group, send email to grp...@googlegroups.com. >>>>>> 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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/251450e2-0f9f-4e00-a22e-d43c0c22bcb2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
