On Tue, Nov 25, 2003 at 11:49:36AM -0000, Bas Scheffers wrote: > Andrew Piskorski said:
> > I suspect that re-initializing a Tcl interpreter to a known state > > probably isn't nearly as impossible to do efficiently as you seem to > > think. (Which is kind of interesting, so perhaps some guru will > > comment further.) > Well, then why doesn't any Tcl based web app product do it? (AOLserver, > Vignette, mod_tcl) Remember that anything more than a few milliseconds is > too slow. If your app is currently able to handle 20 requests a second, > something that takes 50ms extra to do, halves that number. My guess is because no one cares. AFAIK there hasn't been any compelling market for that feature, and even if it is somehow feasible to do, I doubt that it's EASY! > > Safe-Tcl or something like it might be relevent there. > Could work and be quite fast. Create all user procs in one master. > (rewriting the procedure name) On each request, create a safe interp with > aliasses to only that user's procs and execute as that user's UID. Not too > familiar with Safe-tcl, though. But t does require some re-engineering, > basicaly making Tcl multi-user, which is what I suggested needed to be > done in an earlier post to make safe and fast multi-user hosting possible. In that case, why not just give each user his own AOLserver process? If you configure the thread settings appropriately I bet you could get the memory footprint down to something pretty small. Yes, for 100 such processes, the total memory footprint would still be quite a bit larger than if you could somehow stuff those 100 independent servers into 1 process and let them all reference the same read-only Tcl procs, etc. But I bet it would work ok. Also (and I'm speaking largely from ignorance here), most low-end hosting services are still running Apache exclusively in multi-process (not multi-thread) mode anyway, right? So would that "100 AOLserver processes for 100 websites" actually be any more resource hungry than the equivalent typical low-end shared hosting Apache/PHP configuration? Hard experience or numbers here would be interesting, if anyone has them. But anyway, is there ANY real market for very low-end cheap shared AOLserver hosting at all? Whether we like it or not, Apache owns that market, and other than pure academic (all us software engineers helping to educate each other), bottom dollar shared hosting is the only reason I can think of to be looking into these different sorts of "1 process, but 100 different independent websites each completely protected from each other" models. Is that what you were thinking about here Bas, you want to use something like that to bring AOLserver to the masses? If I ran a massive low-end hosting service like that maybe I'd want to play with that, but I don't see the market for it. Right now anyone who knows they want to use AOLserver is almost by definition a relatively sophisticated user, and they're going to prefer the current, more powerful "I have my own AOLserver process and can do whatever I want with it" model if they can get it. So my guess is nearly all the potential users of such a low-end service don't care about Apache vs. AOLserver at all, they just want something cheap. So, if the users don't care, would the (much more informed) people running this large cheap hosting service care? Would AOLserver give them some big win over Apache (e.g., automatic management, reliability, performance)? I don't know, but my guess is, probably not. Not unless they were using AOLserver for other things too (e.g., high end hosting of sophisticated database backed websties), and wanted to leverage their in-house AOLserver expertise by using it for their low-end shared hosting too. Maybe. And if a hosting company or two like that probably exist somewhere, but not very many of them. It would be fun to be really well contradicted on this, though! -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
