I have been checking my test FCGI script from time to time in the last couple hours. I just saw that the counter reset to 0 after some time of inactivity - more than 30 mins I think.

If I click on it continuously after the first click, the counter increments by one each time. I can now better appreciate a little more what persistence means.

This ability to respond to a request without spawning a new process each time is indeed a very attractive feature to have. But until today, I didn't know it comes with the cost of using up server resources. Will have to try it out to see how it works on a shared server.

In a shared hosting environment it is normal for the webserver to get a graceful restart whenever a new user is added or an existing user is deleted. There can be other events that trigger a graceful as well. A graceful restart will cause a new apache process to start accepting connections, and the old process will then shut down after the last open connection ends either through completing the transaction or timing out (whichever comes first).

If your data is not written to a more persistent data store it wouldn't surprise me at all for in-memory data to fall out of scope when a restart happens. This typically won't happen during a request, but between requests all bets are off. On a shared host serving possibly hundreds of users' content, restarts can happen fairly regularly. Within a given transaction your data's integrity is pretty reliable. Between transactions I would work pretty hard to assure I'm not relying on in-memory persistence. The best approach really is to use scoping carefully to avoid data being relied upon spanning across multiple requests, and to leverage the persistent storage options provided by the host; usually a database or the filesystem.




Dave

Very helpful and informative comment. Thanks a zillion!