Path: news.cs.au.dk!not-for-mail From: Flemming Gram Christensen Newsgroups: comp.lang.beta Subject: Re: BETA for CGI Date: 20 Jun 2000 16:15:22 +0200 Organization: University of Aarhus, Department of Computer Science (DAIMI) Lines: 82 Message-ID: References: <20000619173906.8583.qmail@noatun.mjolner.dk> <8ilv4j$8tqm$1@xinwen.cs.au.dk> NNTP-Posting-Host: odin.mjolner.dk X-Trace: xinwen.cs.au.dk 961510524 322633 255.255.255.255 (20 Jun 2000 14:15:24 GMT) X-Complaints-To: news@cs.au.dk NNTP-Posting-Date: 20 Jun 2000 14:15:24 GMT X-Newsreader: Gnus v5.7/Emacs 20.4 Xref: news.cs.au.dk comp.lang.beta:12460 Erik Corry writes: > Sascha Kimmel wrote: > >> > (in BETA) per second - if your file has a size of 1MB this means starting > >> > 50 of these files as fast as possible, so that the clients don't have to > >> > wait and "wasting" your RAM with 50MB of code. > >> > >> Most of this should be shared between the instances, so the RAM use > >> would be much smaller. Also if it is called frequently, it would be > >> cached, so it doesn't have to be read in from disk every time. > > > What type of chaching mechanism do you mean? > > A normal disk cache like every operating system uses so as not to > wait for the disk too much. > > On most OSs these days, different instances of the same program > share memory pages with each other and with the disk cache using > copy-on-write. This means that the page is marked unwritable, but > if the program tries to write to the page then an exception occurs, > and the OS gives the program its own copy of the page, which it > is allowed to write. The net effect is that every process appears > to the app writer to have its own memory, whereas in fact many pages > are shared between apps. > > In terms of Unix system calls: > > If a process is created using fork, then it shares both code and > data pages with at least one other instance (the parent). It also > shares copy-on-write pages that were written before the fork, but > haven't been written since. If the process is created with > fork+exec then it shares only unmodified code pages with other > instances of the same program or library. In both cases unwritten > pages that come from executable files on the disk are shared > with the disk cache. > > >> With a perl CGI the perl interpreter would be shared in the same > >> way, but every time you start the perl script the interpreter has > >> to compile the script to its own internal format. > > > Yes, of course - but the Perl interpreter is very small! > > Well, on my Linux system, the perl interpreter is 516828, but it > also uses parts of the following shared libraries (DLLs): > > -rwxr-xr-x 1 root root 344890 Sep 20 1999 /lib/ld-linux.so.2 > -rwxr-xr-x 1 root root 4118299 Sep 20 1999 /lib/libc.so.6 > -rwxr-xr-x 1 root root 64595 Sep 20 1999 /lib/libcrypt.so.1 > -rwxr-xr-x 1 root root 792313 Sep 20 1999 /lib/libdb.so.3 > -rwxr-xr-x 1 root root 74663 Sep 20 1999 /lib/libdl.so.2 > -rwxr-xr-x 1 root root 540120 Sep 20 1999 /lib/libm.so.6 > -rwxr-xr-x 1 root root 372604 Sep 20 1999 /lib/libnsl.so.1 > -rw-r--r-- 1 root root 26041 Oct 15 1997 /usr/lib/libgdbm.so.2 > > so it's almost 7 Mbytes in all. Not all of this needs to be in > memory of course, and like I said, most of this is shared between > instances of perl. The real cost is compiling the perl script down > to byte code every time a CGI script is called. > > > mod_beta ? :) > > :-) > :-) Using distribution or standard TCP communication it is not hard to make your own dedicated server. You can use coroutines to handle each 'web-session'. The web-server can use a small program, written in Perl, say, to communicate with the BETA programmed server. To my knowledge at least two projects has been done this way. Regards Flemming > -- > Erik Corry corry@mjolner.dk -- /Flemming Gram Christensen