[Zope] Zope slow if left unused for hours

[Tim Peters]

[Jeff Rodriguez]
>> I'm running Zope with Plone, specifically the windows installer
>> version distributed on the Plone website. The first time I hit the
>> site (even the ZMI) the first page takes a long time to load;
>> everything after that is speedy.

Hmm.  That explanation doesn't appear to match the Subject line -- and
that's why you're getting explanations about initial startup.

>> I'm thinking it's some sort of caching issue but I'm not sure where to
>> look to remedy the probelm. I am not running debug mode either.

[Jonathan Hobbs]
> We encountered the same problem, and agree that its probably a cache-loading
> issue.  We never discovered the cause, but we have a work-around:  we run a
> cron job which does an http request to grab a page from the web site every
> 10 minutes - this seems to keep the cache 'fresh'.

Taking the Subject as being the real issue here, there's another
problem that may be unique to Windows:  for inscrutable reasons at
inscrutable times, Windows routinely swaps out RAM that hasn't been
touched by a process "for a while", and regardless of whether it
actually needs the RAM for something else.  You can watch this by
bringing up Task Manager, and ensuring that the "VM Size" (amount of
address space committed byo the process) and "Mem Usage" (amount of VM
address space actually in RAM) columns are displayed.  The latter can
(although this is extreme) shrink to kilobytes if a process is idle
"long enough", no matter how much VM the process has committed, and
even if the machine is otherwise idle the whole time.

In a previous life, I worked on an NT-based call-center telephone
speech recognition system.  That's a very intense application,
requiring 100s of MBs of RAM.  Machines running it ran nothing else,
and had plenty of RAM.  Nevertheless, in the middle of the night when
call traffic was light, NT would swap the whole thing out to disk. 
Then a call would come in, and it could take literally minutes for NT
to swap enough of the app back into RAM to process the call.

I don't recall whether we ever found a slick solution.  The first
brute-force wormaround worked pretty well:  when the app was otherwise
idle, we had another process trick it into thinking it was getting a
phone call and hearing speech.  That kept most of it RAM all the time.