[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.