MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: on-the-fly guest creation
> < Hope this helps. We use this method to handle web connections to our moo,
> < except instead of making children of $guest, we make children of the new
> < player class $web_user (and instead of connect, the verb to login is
> < GET/POST).
> Ouch, I personally wouldn't suggest this. There is a bit of overhead
> involved in creating an object,
Oh, not really. If creating objects is slow, we should fix that,
rather than fooling around with pools of object caches.
> and you do not want an HTTP daemon to be
> slow (it is easilly noticeable).
Agreed, but you have to understand what your goals are. In my highly
unscientific test, I found that JHM time from click to appearance of
new page is well under a second. But talking to our normal NCSA web
server got ranges from near instantaneous to a second.
> I would suggest keeping a cache around
> of http objects which are nearly initialized. Upon connect you set
> whatever parameters are needed, do whatever. Upon disconnect you reset
> the values to defaults. Then grow/reduce the cache as is necessary.
> Even web daemons (NCSA, Apache) are moving to this cache design, rather
> than forking off new processes for each connection. In the long run, the
> overhead of initializing a new object for each connection isn't worth the
> return, and can be even more messy.
I can't see how trying to clean up an already used http object is
going to be any cleaner than creating one fresh. And the standalone
Web demons have other problems--in particular, the rise of inlined
images put stress on them that most MOO-based web servers will never
have to face.
Jay Carlson
nop@io.com nop@ccs.neu.edu nop@kagoona.mitre.org
Flat text is just *never* what you want. ---stephen p spackman
References:
Home |
Subject Index |
Thread Index