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 <racketus...@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 <racketus...@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.kemp...@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 ____________________ Racket Users list: http://lists.racket-lang.org/users
