[Xitami] Memory allocation

[Paul Reid]

 >  is there anyway to provde the application more memory so that if it 
needs it, it is available.

It's not Mac OS/6. Any 32-bit Win-app can request 2GB at any time. The 
whole point of virtual memory is that the app does not know if the 2GB 
is DRAM or hard drive or small angels with clay tablets.

I've run Xitami and CGI in 8MB (obviously not Win2003). If a runaway 
script asks for 6MB, so the total system demand is 12MB in 8MB RAM, the 
request is satisfied though the system gets slow. The fix is to be sure 
you always have that 5MB (or whatever) to spare.

Use Task Manager. "PF Usage" should flutter far below the Physical 
Memory number. Launching a CGI interpreter will spike it; VB6 runtime 
loads over 1MB of junk into RAM, but gives it back when it exits.

My Xitami on Win2003 box is idling at 173MB total. Xitami is 5th on the 
process list with about 5MB used. Launching a small Perl script barely 
registers.

Task Manager also shows CPU Usage. When code is not waiting on disk or 
I/O, this always spikes to 100%, but if it spikes and falls in a blink 
then you are not really limited by CPU.

 >  with 6Gb of memory

I think Xitami has more than enough memory. Also VB, Perl, PHP.

 > The biggest slow down of the server is watching cgi-bin scripts kick off.

What interpreter, and how heavy are the scripts? Even back in 133MHz 
128MB RAM days, we could get away with quite sloppy code. One of my 
scripts opens and reads several text files, twice, because it was less 
programmer work than doing it once and the result was plenty fast. 
Another one must skim every file in a folder to get type and summary 
info, and it runs in a blink. If you are opening gigabyte databases, you 
probably don't want the script doing that, you want a persistent 
database server application which is already primed when the CGI asks 
for data.

Apache has a way to keep PHP running all the time so you don't suffer a 
PHP interpreter load on every hit. But that only helps if you have a LOT 
of hits on scripts so easy that interpreter load-time exceeds script 
runtime.

Interpreted scripts can sometimes be compiled, and run somewhat faster, 
if they are not disk-bound.

In short: you need to know what's really taking time, and what resource 
it is bound in. And with 6GB, it seems unlikely that RAM-cram or memory 
allocation is the problem.

-- 
Paul Reid
System Administrator
Music Department
Mason Gross School of the Arts