Rapid succession of refreshes from authenticated user can overload server

We're running Drupal 5.1 on a VM with 1GB RAM and 2.4GHz CPU w/ Apache 2 and PHP 5
The problem described below also occurs in Drupal 4.x
At the end of the post is a practical way to alleviate the problem

Using modules: Core(Aggregator, Blog, BlogAPI, Comment, Menu, Path, Profile, Search, Taxonomy, Upload), ldapauth, ldapgroups, Audio (getID3, Images, Import, iTunes), Event (Basic, All Day), Image(Attach Image), Backup, DHTML Menus, IMCE, Panels, Pathauto, SiteUserList, SiteUserListRoles, Taxonomy Theme, TinyMCE, Video(Costum, ffmpeg, image, params), Views(RSS, Themewizard)

This is just a test setup with only one user accessing it.

When logged on to the site (so each request results in a complete page rebuild) holding down the refresh key on the client results in many apache children being spawned and 100% CPU usage. Holding down for 10 seconds can result in complete server lockup for at least 20-30 seconds. In worst case scenarios the server will not recover in any reasonable amount of time. This doesn't seem to be a problem for anonymous users when caching is turned on, but we expect to have many authenticated users on at once. How often might one hold down the refresh key? It happened within 5 minutes in our first training session on our production site, resulting in complete server lockup, so maybe pretty often.

We poured over all the Apache, PHP and MySQL settings and adjusted everything that seemed related, but to no avail. Installing eAccelerator helps some, but only a little.
We considered installing the mod_limitipconn Apache module to limit clients to just a few concurrent sessions, but this required a rebuild of Apache on CentOS which we'd like to avoid.

Here's a workable fix:

Edit sessions.inc:
add the following around line 38 - immediately after the line: if ($user && $user->uid > 0) {

db_query("update sessions set timestamp=0 where sid='$key'");

Edit bootstrap.inc
add the following around line 812 - immediately after the line: session_start();

####
#jvp 7-25-07: try to catch rapid succesive reloads and send a delayed-reload header instead of trying to build the page a hundred times
#This works by testing $user->timestamp. session.inc, function: sess_read() has been modified to zero out the timestamp in the database for user's session after it reads user's session data. This means that successive requests performed before the current session ends and writes the new timestamp will get a timestamp of zero. Code below will return a delayed reload header to the client and exit in this case.
#If a page build completes in less than one second it writes back the same timestamp. If a subsequent request comes in during that same second, code below also catches this and send delayed-reload header if the current time is the same as the timestamp
#Sometimes, rapidly successive requests will all read the same timestamp before the first request can zero it out. In this case, all such requests are considered valid. This results in wasted page builds, but not so much to max out the CPU. A more reliable way to catch the reloads might be to use mod_limitipconn in apache to limit the number of concurrent connections one client can have, but that might require recompiling apache.

global $base_url,$user;

#determine whether to build page or delay-reload
if (isset($user->timestamp) && ($user->timestamp==0 || (time()-$user->timestamp)<1)) {

#rebuild requested url
$url="$base_url/".preg_replace('/^q=/','',$_SERVER[QUERY_STRING]);

#tell client to reload requested url in 1 second
header("Refresh: 1; $url");

#display a link in case the client browser doesn't redirect OR
#comment out following line for transparent redirection
print "Loading page: $url";

#exit Drupal
module_invoke_all('exit', $url);
exit();
}
####