MOO-cows Mailing List Archive


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

Flat text is just *never* what you want.   ---stephen p spackman


Home | Subject Index | Thread Index