[racket] Web server

I just read "Places: Adding Message-Passing Parallelism to Racket" and wanted to pass on a link to any other Racket newbies interested in parallelism:

https://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf

This was good to read:

"We expect to develop new constructs for parallelism in Racket that internally combine futures and places to get the advantages of each."


I read the paper quickly, and I may have more questions later, but one question did pop up after reading the comparison between Python's MP lib and Racket on page 11. From that, it appears that Python's solution may be able to take advantage of the copy-on-write aspect of forking.

Is that not the case with Places? If so, what was the rationale in not utilizing copy-on-write?

Thanks,
Brian

On Jul 17, 2014, at 10:49 AM, Brian Adkins wrote:

> [forgot *again* to reply-all and only sent this to Jay initially - resending to group]
> 
> Thanks for the response Jay.
> 
> I may have glossed over the parallelism & concurrency aspects a bit too much when I first read those sections in the Racket Guide. I now see in 20.1 re: Futures:
> 
> "The level of parallelism available from those constructs, however, is limited by several factors, and the current implementation is best suited to numerical tasks."
> 
> and in 20.2:
> 
> "The place form creates a place, which is effectively a new Racket instance that can run in parallel to other places, including the initial place."
> 
> "Places" appears to be similar to my current approach of having multiple Ruby/Rails processes handle web requests. In the case of Ruby/Rails, it's a very inefficient use of memory, i.e. the amount of RAM needed to fully utilize all cores is *much* higher than it should be when spinning up multiple app server processes that each load the entire Rails framework. Each Rails process is essentially single-threaded.
> 
> I was hoping to gain a big improvement of Ruby/Rails with Racket, and that may be possible even with the current implementation (both Ruby & Rails are performance-challenged), but can you give me some idea of the level importance multi-core performance is in the Racket community moving forward? I'm taking a fairly long term perspective with Racket, so the "roadmap" is as important to me as the current implementation.
> 
> I'm referring to Racket in general, not just the web server.
> 
> I haven't done much research or testing yet, so maybe a combination of Places and Threads will be sufficient for my needs. Maybe one Place per CPU core w/ multiple threads to keep the CPU busy while some threads are blocked on I/O requests.
> 
> 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
> 
> 
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users