in reply to Script caching?

Some ideas off the top of my head, prolly not worth too much...

Is the script in mod_perl? I don't know mod_perl but from what I understand there is caching involved.
Is there a high load on the machine, or a really high http timeout setting? Perhaps it actually took an hour for those two instances to complete.
Are you sure there's only one copy? The users don't have bookmarks pointing to the old one or anything?
Is the script on a cluster of machines maybe?

john

Replies are listed 'Best First'.
Re: Re: Script caching?
by Dr. Mu (Hermit) on May 17, 2002 at 06:59 UTC
    Is the script in mod_perl? No.

    Is there a high load on the machine? Can't be sure. It's shared with other sites. My site has light traffic.

    or a really high http timeout setting? Not sure that's relevent, since this was a new session for the recorded client.

    Perhaps it actually took an hour for those two instances to complete. Not likely. They were consecutive, about 55 seconds apart, and from the same client.

    Are you sure there's only one copy? Yes, this particular script has only ever had one name and one location. When I FTP changes, I overwrite the old copy.

    Is the script on a cluster of machines maybe? Not according to my hosting service.

    One other odd observation: After the two anomalous queries, the same client made nine further queries which logged normal responses.

      Even if the script is written as vanilla CGI, if it's being run on apache with mod_perl, there are a couple ways that it could be set up to optimize performance by caching CGI scripts to avoid having to reload and recompile them every time they're referenced.

      By default, apache request-handling processes kill themselves after handling 50 requests, at which point their cached data is lost and the replacement process reloads everything. I suspect that the two anomalous log entries were the result of a process which had previously handled requests for your old script and didn't notice that there was a new version. By now, though, it is long dead and you shouldn't see any artifacts of the old version in the future.

        Oh, if only this were true. Like the boogey man, this one doesn't seem to want to die and has reared its ugly head with other clients. Unfortunately, I discovered too late that I should be recording $$ (the process ID) in the log file, so I could ask my hosting service to kill it.