I'd be interested in contributing on this front. Has there been any 
additional movement on this in the last 3 years?

On Saturday, March 5, 2016 at 10:49:13 AM UTC-8, Craig Tiller wrote:
>
> If anyone is looking for a starter project within core I'd be happy to 
> work with them to get SO_REUSEPORT support done.
>
> On Fri, Mar 4, 2016, 9:59 AM Andrew Lazarus <[email protected] 
> <javascript:>> wrote:
>
>> fork/SO_REUSEPORT support would be awesome. I think the domain sockets 
>> will work for now. Will report back after testing with nginx.
>>
>>
>> On Thursday, March 3, 2016 at 7:05:43 PM UTC-8, Craig Tiller wrote:
>>
>>> I've been thinking a little about this recently but haven't had the 
>>> chance to write anything down. I think there's some big opportunities to 
>>> support a fork/SO_REUSEPORT style concurrency for core wrapping languages 
>>> (so #3).
>>>
>>> gRPC core can already use UNIX domain sockets. When adding a port use 
>>> unix:path_to_socket, and similarly when creating a client side channel.
>>>
>>> On Thu, Mar 3, 2016, 5:57 PM Andrew Lazarus <[email protected]> wrote:
>>>
>> I posted a reply to a python question 
>>>> <https://groups.google.com/forum/#!topic/grpc-io/PnBfxXhpgLg> but I 
>>>> think this deserves its own thread.
>>>>
>>>> MRI's GIL limits each ruby process to a single core. To utilize 
>>>> multiple cores, you need to use multiple processes. To work around this 
>>>> limitation, a "standard" ruby server deploy uses multiple processes 
>>>> listening on a single port or domain socket. Using puma (a threaded 
>>>> HTTP/1.1 server) as an example, here is a standard setup:
>>>>
>>>> nginx accepts external requests: it is configured as a reverse proxy 
>>>> that terminates SSL (SSL termination further helps reduce CPU load on the 
>>>> ruby processes). A puma master process listens on a domain socket or port 
>>>> and then spawns a set of worker processes that actually handle the 
>>>> requests.
>>>>
>>>> There are a couple solutions I can think of for gRPC.
>>>>
>>>> 1) nginx as a reverse proxy with N gRPC server processes listening on N 
>>>> different ports. Nginx would terminate SSL in this case. This solution is 
>>>> very sub-optimal since it requires N ports for each service.
>>>>
>>>> 2) Same as #1, but use domain sockets. This would require changes to 
>>>> gRPC core so that it can listen on domain sockets in addition to ports. 
>>>> This is preferable to #1.
>>>>
>>>> 3) Add a process / socket management layer that listens on a socket 
>>>> then forks gRPC server subprocesses that inherit the parent socket. This 
>>>> seems like the best solution, but is probably the most work. It would 
>>>> require changes to gRPC core + writing the process management layer.
>>>>
>>>> -- 
>>>> 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/b3f73c6d-5270-43b8-aef9-370d82bea61a%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/grpc-io/b3f73c6d-5270-43b8-aef9-370d82bea61a%40googlegroups.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] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/39f7fd69-a7a5-464c-ab6a-2f306448fdbf%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/grpc-io/39f7fd69-a7a5-464c-ab6a-2f306448fdbf%40googlegroups.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/fe497429-39ce-4c3e-badc-8cb4ec536f87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to