[racket] Web server

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