Re: custom authentication functions

>On Fri, 29 Mar 1996, Mike Meyer wrote:
>> Not compared to the overhead of starting a CGI in the first place :-(.
>
>Again, that would depend on how CGIs are implemented. I can easily
>imagine a server implementing Tcl CGIs as simply sourcing and then
>invoking the code in an interpreter, for example.

Yes, this is similar to what we've done at Destiny in our server
with our scripting language `rsl'. The server is built upon rsl
(which it additionally uses for configuration and extensibility),
and when an rsl CGI script is to be executed, the server can optionally
simply load the script and execute it internally. This has proven
to work extremely well, not only in performance gains over forking,
but also in the much wider capabilities the scripts have in talking
to the server, since the server itself is implemented as scriptable
components.. not to mention script caching and pre-loading for
even higher performance. Pardon the plug, but I think it's pretty cool.


>> I sincerely hope that for most people, only a small fraction of hits
>> are going to be CGI,
>
>That's what everyone hopes. That's why CGI has so much overhead. ;-)
>
>Seriously, tho, we have web servers where every single hit is a CGI
>script. That makes the servers that do things like forking off a dozen
>copies of themself useless, since they all exec and die anyway. A better
>solution for *us* would be as I said above.

I hear you ! :-)

It is an especially difficult performance problem for sites which try to
maintain user sessions information and provide much more
dynamic, user-specific content -- most of those are going to be CGI hits.

-Russell Holt


=(Russell Holt)====-===-==-=-=--=---=---- --- -- - -  -   -    -     -
holtrf@destinyusa.com   .........      http://www.destinyusa.com/russ/
R&D, Destiny Software               .-...-........-...-.. ....---.-..-

Received on Friday, 29 March 1996 17:38:48 UTC