Log:
Fixed a couple misspellings, encoded some entities, and changed 'behaviour' (British) to 'behavior' (US).
Chris Pepper
Index: perf-tuning.html =================================================================== RCS file: /home/cvspublic/httpd-docs-1.3/htdocs/manual/misc/perf-tuning.html,v retrieving revision 1.21 diff -u -r1.21 perf-tuning.html --- perf-tuning.html 2000/09/12 02:29:10 1.21 +++ perf-tuning.html 2000/11/05 05:11:18 @@ -40,7 +40,7 @@ it does some things which slow it down.
<P>Note that this is tailored towards Apache 1.3 on Unix. Some of it applies -to Apache on NT. Apache on NT has not been tuned for performance yet, +to Apache on NT. Apache on NT has not been tuned for performance yet; in fact it probably performs very poorly because NT performance requires a different programming model.
@@ -257,15 +257,15 @@
for (;;) {
fd_set accept_fds;- FD_ZERO (&accept_fds);
+ FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
- FD_SET (i, &accept_fds);
+ FD_SET (i, &accept_fds);
}
- rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
- if (FD_ISSET (i, &accept_fds)) {
+ if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
@@ -315,15 +315,15 @@
for (;;) {
fd_set accept_fds;- FD_ZERO (&accept_fds);
+ FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
- FD_SET (i, &accept_fds);
+ FD_SET (i, &accept_fds);
}
- rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
- if (FD_ISSET (i, &accept_fds)) {
+ if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
@@ -406,7 +406,7 @@
about single socket servers? In theory they shouldn't experience
any of these same problems because all children can just block in
<CODE>accept(2)</CODE> until a connection arrives, and no starvation
-results. In practice this hides almost the same "spinning" behaviour
+results. In practice this hides almost the same "spinning" behavior
discussed above in the non-blocking solution. The way that most TCP
stacks are implemented, the kernel actually wakes up all processes blocked
in <CODE>accept</CODE> when a single connection arrives. One of those
@@ -414,7 +414,7 @@
the kernel and go back to sleep when they discover there's no connection
for them. This spinning is hidden from the user-land code, but it's
there nonetheless. This can result in the same load-spiking wasteful
-behaviour that a non-blocking solution to the multiple sockets case can.
+behavior that a non-blocking solution to the multiple sockets case can. <P>For this reason we have found that many architectures behave more
"nicely" if we serialize even the single socket case. So this is
@@ -475,7 +475,7 @@
select (s for reading, 2 second timeout);
if (error) break;
if (s is ready for reading) {
- if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+ if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
break;
}
/* just toss away whatever is read */
@@ -517,7 +517,7 @@<P>Historical note: The Linux port of Apache didn't start to use shared memory until version 1.2 of Apache. This oversight resulted -in really poor and unreliable behaviour of earlier versions of Apache +in really poor and unreliable behavior of earlier versions of Apache on Linux.
<H4><CODE>DYNAMIC_MODULE_LIMIT</CODE></H4> @@ -721,7 +721,7 @@ <CODE>Timeout</CODE>.
<P>It may even be the case that <CODE>mmap</CODE> isn't -used on your architecture, if so then defining <CODE>USE_MMAP_FILES</CODE> +used on your architecture; if so then defining <CODE>USE_MMAP_FILES</CODE> and <CODE>HAVE_MMAP</CODE> might work (if it works then report back to us).
<P>Apache does its best to avoid copying bytes around in memory. The
@@ -753,7 +753,7 @@
are buffered before writing. At no time does it split a log entry
across a <CODE>PIPE_BUF</CODE> boundary because those writes may not
be atomic. (<EM>i.e.</EM>, entries from multiple children could become mixed together).
-The code does it best to flush this buffer when a child dies.
+The code does its best to flush this buffer when a child dies.
<P>The lingering close code causes four system calls:
@@ -857,7 +857,7 @@ 1.3 is multithreaded on NT. There have been at least two other experimental implementations of threaded Apache, one using the 1.3 code base on DCE, and one using a custom user-level threads package and the 1.0 code base; -neither is available publically. There is also an experimental port of +neither is publicly available. There is also an experimental port of Apache 1.3 to <A HREF="http://www.mozilla.org/docs/refList/refNSPR/";> Netscape's Portable Run Time</A>, which <A HREF="http://www.arctic.org/~dgaudet/apache/2.0/";>is available</A>
-- Chris Pepper | Shooting Gallery Interactive | 212 905-2200 Mac OS X Software: <http://www.mosxsw.com/>
