Path: news.cs.au.dk!not-for-mail From: Erik Corry Newsgroups: comp.lang.beta Subject: Re: BETA for CGI Date: 19 Jun 2000 20:17:23 GMT Organization: =?ISO-8859-1?Q?Mj=F8lner?= Informatics ApS Lines: 63 Distribution: world Message-ID: <8ilv4j$8tqm$1@xinwen.cs.au.dk> References: <20000619173906.8583.qmail@noatun.mjolner.dk> NNTP-Posting-Host: amigo.cs.au.dk X-Trace: xinwen.cs.au.dk 961445843 292694 255.255.255.255 (19 Jun 2000 20:17:23 GMT) X-Complaints-To: news@cs.au.dk NNTP-Posting-Date: 19 Jun 2000 20:17:23 GMT User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (IRIX64/6.5 (IP27)) Xref: news.cs.au.dk comp.lang.beta:12446 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 ? :) :-) -- Erik Corry corry@mjolner.dk