I noticed that when I restarted apache, the problem was greatly reduced,
if not altogether absent. All page loads were very fast. When apache
restarts, there are initially only a couple of httpd processes. The
delays seemed to be occurring with apache processes which had been up
for a good while (last night there were 11 of them). During their
uptime, I had updated the html files on the server quite regularly via
ssh from my development machine. Is it possible that there was some kind
of memory leak or other kind of buildup over time, as a result of the
rapidly changing html sources? There is no heavy processing going on in
these files, apart from simple SQL selects and resulting loops to output
the results.
The server has 512Mb of memory, so it is unlikely that memory is running
low. Also it is no slouch, being a dual 500 MHz Xeon box from Penguin
Computing. It is usually lightning quick, which is why the problem was
so noticeable. This is worrying, and I will try to pin down any factors
which bring it on or make it go away. It is particularly hard to nail
these kinds of things when they are not easily reproducible. The only
thing that seems to have affected it so far was restarting apache, but
that's not exactly a fix...
Also I will try some of the things you suggest.
Thanks
-Neil
Gerald Richter wrote:
>
> > How long should apache (and Embperl) be caching pages?
> >
>
> forever, as long as the source didn't change. There is no clean way to
> remove already compiled Perl code from memory
>
> > When does Embperl decide to recompile (apart from when a page source
> > changes)?
> >
>
> Only when a page changes.
>
> The second source of delays, that could be possible, is that the Apache
> child is swaped out to disk, also this is unlikely when you machnie does
> nothing else.
>
> You can set the dbgProfile, dbgSource, dbgEval and dbgEvalDef debugging
> options and watch the embperl.log file. Everytime a page get's recompiled
> you see the lines starting with DEF:, also every sourceline in the logfile
> will now contain a timestamp, so you can see if there is any processing
> inside the page that takes such a long time.
>
> Gerald
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925131
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
