[racket] Web server
Thanks, I think we're on the same page.
I was considering something outside of the Racket web server handling the affinity. For example, the nginx web server / load balancer being responsible to send subsequent requests from a client to the same server process that handled the initial request.
On Jul 17, 2014, at 10:38 AM, Jay McCarthy wrote:
> Hi Brian,
>
> Stateful continuations have to be invoked from the process that
> capture them. That's like session affinity. The reason I said it
> doesn't make a lot of sense is that continuations don't really have a
> "parent" and aren't really in a "session". There's not necessarily a
> connection between one continuation and another.
>
> Jay
>
> On Thu, Jul 17, 2014 at 10:33 AM, Brian Adkins <racketusers at lojic.com> wrote:
>> Jay:
>>
>> Can you clarify your statement, "Session affinity doesn't really make a lot of sense in the continuation context, fwiw." ?
>>
>> I haven't really dug into the web server yet, so I may simply be misunderstanding how it works, but at least in the case of stateful continuations, I thought it was important for all of a user's subsequent requests to go to the same process that served the first request since there would be state stored in the memory of the web server process.
>>
>> Is that not the case? Or are all continuations serialized to disk so that any Racket web server process (assuming there are multiple instances running) could serve a subsequent request for any continuation?
>>
>> To be clear, the scenario I'm envisioning is that of an nginx web server handling all incoming http requests, serving static files itself and proxying all other requests to a set of Racket web server instances using some sort of load balancing such as round robin. I assumed that if I begin my session with process-1 and then the next request was served by process-2, it would fail.
>>
>> Thanks,
>> Brian
>>
>> On Jul 16, 2014, at 10:17 PM, Jay McCarthy wrote:
>>
>>> It wouldn't have a big impact on the server. The big question is how
>>> to effectively use multi-core in Racket programs generally.
>>>
>>> Futures are really only good for numerical codes that stay in the JIT,
>>> which doesn't sound like most Web programs. That said, it is trivial
>>> to implement:
>>>
>>> #lang racket/base
>>> (require racket/future
>>> web-server/servlet-env
>>> web-server/http)
>>>
>>> (define (fib n)
>>> (if (< n 2)
>>> 1
>>> (+ (fib (- n 1))
>>> (fib (- n 2)))))
>>>
>>> (define (start req)
>>> (touch
>>> (future
>>> (λ ()
>>> (response/xexpr
>>> `(html
>>> (body
>>> (p "It's "
>>> ,(number->string
>>> (fib (random 20)))))))))))
>>>
>>> (serve/servlet start)
>>>
>>> Boom! That's a servlet that uses multi-core to handle every request...
>>> of course, it probably doesn't pay in this or most other programs.
>>>
>>> Places are for more coarse-grained things and you can pass file
>>> descriptors, so it's feasible to have a TCP accepter that feeds work
>>> to a group of places servicing the requests. However, places must not
>>> use mutation to communicate higher-order values (they can communicate
>>> flat values like numbers with mutation), so they couldn't share
>>> continuations. It would be trivial to use serializable continuations
>>> or to implement a continuation manager that stored all the
>>> continuations in a single place. Session affinity doesn't really make
>>> a lot of sense in the continuation context, fwiw.
>>>
>>> My guess is that you could spend less than 100 lines to implement the
>>> continuation manager and the place-based worker setup. (This is based
>>> on the normal server setup just being 127 lines and the manager
>>> interface being implemented in as little as 40 lines.) This might be
>>> worth it.
>>>
>>> Jay
>>>
>>>
>>> On Wed, Jul 16, 2014 at 4:09 PM, Brian Adkins <racketusers at lojic.com> wrote:
>>>> I haven't looked into the Racket web server much yet, so I'd like to understand the implications of this.
>>>>
>>>> My experience is with stateless http app servers (primarily with Unicorn Ruby servers at the moment), so firing up a number of worker processes and having something like nginx proxy to them works well to fully utilize all cores.
>>>>
>>>> I think I read that the Racket web server makes use of continuations, so I expect some sort of process affinity would be necessary, where a given user's requests are always proxied to the same worker process - is that right? Is it common to use multiple web server processes in Racket web apps?
>>>>
>>>> In your estimation, what is the feasibility of adding multi-core support to the Racket web server? For example, is it reasonably feasible and on the current roadmap, or would it require massive changes to the web server?
>>>>
>>>> Thanks,
>>>> Brian
>>>>
>>>> On Jul 16, 2014, at 8:42 AM, Jay McCarthy wrote:
>>>>
>>>>> It does not use multiple cores if they are available.
>>>>>
>>>>> Jay
>>>>>
>>>>> On Wed, Jul 16, 2014 at 7:02 AM, Sean Kemplay <sean.kemplay at gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am interested in the racket web server for some micro services. Just
>>>>>> wondering if by default it runs across multiple cores or if it is restricted
>>>>>> to one due to threads in racket.
>>>>>>
>>>>>> Regards,
>>>>>> Sean
>>>>>>
>>>>>>
>>>>>> ____________________
>>>>>> Racket Users list:
>>>>>> http://lists.racket-lang.org/users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jay McCarthy
>>>>> http://jeapostrophe.github.io
>>>>>
>>>>> "Wherefore, be not weary in well-doing,
>>>>> for ye are laying the foundation of a great work.
>>>>> And out of small things proceedeth that which is great."
>>>>> - D&C 64:33
>>>>> ____________________
>>>>> Racket Users list:
>>>>> http://lists.racket-lang.org/users
>>>>
>>>
>>>
>>>
>>> --
>>> Jay McCarthy
>>> http://jeapostrophe.github.io
>>>
>>> "Wherefore, be not weary in well-doing,
>>> for ye are laying the foundation of a great work.
>>> And out of small things proceedeth that which is great."
>>> - D&C 64:33
>>
>
>
>
> --
> Jay McCarthy
> http://jeapostrophe.github.io
>
> "Wherefore, be not weary in well-doing,
> for ye are laying the foundation of a great work.
> And out of small things proceedeth that which is great."
> - D&C 64:33