On Tue, Dec 27, 2011 at 2:26 PM, Galler <lzgal...@optonline.net> wrote: > I'm nearing completion of a web application with stateful server > continuations, and am thinking about future scalability. > > If we limit the discussion to the specific problem of retention of > server-side continuations in gc'd memory (and not to whether server-side > continuations are of value) > > I have two topics of inquiry: > > 1) Physical memory and stateful continuations > > I note that no one has discussed throwing a significant amount of physical > memory at the problem. > > Empirically, is that because garbage-collection of a large heap creates its > own performance problems?
The problem is that URLs are roots. Thus, GC is ineffective at removing them: the memory used by stateful continuations can never be soundly freed. That's why there are unsound techniques like timeouts and the LRU. In the bad old days of the conference manager, before the LRU, I could easily get 3 or 4 GBs of continuations on a 1 GB machine, so I had to reboot it constantly. That's the core reason I wanted to push the stateless continuations. > > 2) The ANF transforms and statelessness > > Apart from the Continue conference application, has anyone deployed a > non-trivial web application using the stateless language transforms? The conference application does not use it nor is it written in Racket. I have written non-trivial applications that use it. > > Alternatively, has the stateless form of Continue been > stress-tested? My applications have not been stress tested. > > Have tradeoffs beyond those listed in item 6 of Jay's 'Automatically > RESTful Web Applications' been identified since its date of publication > (compilation time, execution lag, third part library interaction, > non-serializable data structures) > No others have been identified. In practice, I find the compilation time to be annoying but you get used to it; there is practically no execution lag; the third-party libraries are not a problem at all---once you have `map' it's pretty much all you need---but it is an important technical/academic limitations [*]; and the non-serializable data structures are also not normally a problem if you only depend on things you wrote. Jay [*] Except for contracts and exception handlers. > Thanks very much. > > > > R./ > Zack > ____________________ > Racket Users list: > http://lists.racket-lang.org/users -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 ____________________ Racket Users list: http://lists.racket-lang.org/users
