summaryrefslogtreecommitdiff
path: root/usr.sbin/httpd/htdocs/manual/misc
diff options
context:
space:
mode:
authorJason McIntyre <jmc@cvs.openbsd.org>2005-07-27 20:54:45 +0000
committerJason McIntyre <jmc@cvs.openbsd.org>2005-07-27 20:54:45 +0000
commit018985f75ef615729a745e6922b2fe9bd7bd31bc (patch)
tree520f972075019002808478dd01e9c46ae23224ad /usr.sbin/httpd/htdocs/manual/misc
parent77c6a09cbd49af3a28373fa90768560b070f47cf (diff)
from tamas tevesz:
==> remove of a number of alien platforms ==> remove broken links in sitemap.html ==> remove unreferenced install_1_1.html
Diffstat (limited to 'usr.sbin/httpd/htdocs/manual/misc')
-rw-r--r--usr.sbin/httpd/htdocs/manual/misc/index.html11
-rw-r--r--usr.sbin/httpd/htdocs/manual/misc/perf-dec.html297
-rw-r--r--usr.sbin/httpd/htdocs/manual/misc/perf-hp.html107
3 files changed, 0 insertions, 415 deletions
diff --git a/usr.sbin/httpd/htdocs/manual/misc/index.html b/usr.sbin/httpd/htdocs/manual/misc/index.html
index a97f7cb7b99..50faa72182c 100644
--- a/usr.sbin/httpd/htdocs/manual/misc/index.html
+++ b/usr.sbin/httpd/htdocs/manual/misc/index.html
@@ -96,17 +96,6 @@
<dd>Some notes about ways to improve/optimize Apache
performance on BSD 4.4 systems.</dd>
- <dt><a href="perf-dec.html">Performance Notes (Digital
- UNIX)</a></dt>
-
- <dd>Extracts of USENET postings describing how to optimize
- Apache performance on Digital UNIX systems.</dd>
-
- <dt><a href="perf-hp.html">Performance Notes (HPUX)</a></dt>
-
- <dd>Email from an HP engineer on how to optimize HP-UX
- 10.20.</dd>
-
<dt><a href="perf.html">Performance Notes (General)</a></dt>
<dd>Some generic notes about how to improve the performance
diff --git a/usr.sbin/httpd/htdocs/manual/misc/perf-dec.html b/usr.sbin/httpd/htdocs/manual/misc/perf-dec.html
deleted file mode 100644
index b11b6e680ee..00000000000
--- a/usr.sbin/httpd/htdocs/manual/misc/perf-dec.html
+++ /dev/null
@@ -1,297 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org" />
-
- <title>Performance Tuning Tips for Digital Unix</title>
- </head>
- <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-
- <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
- vlink="#000080" alink="#FF0000">
- <div align="CENTER">
- <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" />
-
- <h3>Apache HTTP Server Version 1.3</h3>
- </div>
-
-
- <h1 align="CENTER">Performance Tuning Tips for Digital
- Unix</h1>
- Below is a set of newsgroup posts made by an engineer from DEC
- in response to queries about how to modify DEC's Digital Unix
- OS for more heavily loaded web sites. Copied with permission.
- <hr />
-
- <h2>Update</h2>
- From: Jeffrey Mogul &lt;mogul@pa.dec.com&gt;<br />
- Date: Fri, 28 Jun 96 16:07:56 MDT<br />
-
-
- <ol>
- <li>The advice given in the README file regarding the
- "tcbhashsize" variable is incorrect. The largest value this
- should be set to is 1024. Setting it any higher will have the
- perverse result of disabling the hashing mechanism.</li>
-
- <li>
- Patch ID OSF350-146 has been superseded by
-
- <blockquote>
- Patch ID OSF350-195 for V3.2C<br />
- Patch ID OSF360-350195 for V3.2D
- </blockquote>
- Patch IDs for V3.2E and V3.2F should be available soon.
- There is no known reason why the Patch ID OSF360-350195
- won't work on these releases, but such use is not
- officially supported by Digital. This patch kit will not be
- needed for V3.2G when it is released.
- </li>
- </ol>
- <hr />
-<pre>
-From mogul@pa.dec.com (Jeffrey Mogul)
-Organization DEC Western Research
-Date 30 May 1996 00:50:25 GMT
-Newsgroups <a
-href="news:comp.unix.osf.osf1">comp.unix.osf.osf1</a>
-Message-ID &lt;4oirch$bc8@usenet.pa.dec.com&gt;
-Subject Re: Web Site Performance
-References 1
-
-
-
-In article &lt;skoogDs54BH.9pF@netcom.com&gt; skoog@netcom.com (Jim Skoog) writes:
-&gt;Where are the performance bottlenecks for Alpha AXP running the
-&gt;Netscape Commerce Server 1.12 with high volume internet traffic?
-&gt;We are evaluating network performance for a variety of Alpha AXP
-&gt;runing DEC UNIX 3.2C, which run DEC's seal firewall and behind
-&gt;that Alpha 1000 and 2100 webservers.
-
-Our experience (running such Web servers as <a
-href="http://altavista.digital.com">altavista.digital.com</a>
-and <a
-href="http://www.digital.com">www.digital.com</a>) is that there is one important kernel tuning
-knob to adjust in order to get good performance on V3.2C. You
-need to patch the kernel global variable "somaxconn" (use dbx -k
-to do this) from its default value of 8 to something much larger.
-
-How much larger? Well, no larger than 32767 (decimal). And
-probably no less than about 2048, if you have a really high volume
-(millions of hits per day), like AltaVista does.
-
-This change allows the system to maintain more than 8 TCP
-connections in the SYN_RCVD state for the HTTP server. (You
-can use "netstat -An |grep SYN_RCVD" to see how many such
-connections exist at any given instant).
-
-If you don't make this change, you might find that as the load gets
-high, some connection attempts take a very long time. And if a lot
-of your clients disconnect from the Internet during the process of
-TCP connection establishment (this happens a lot with dialup
-users), these "embryonic" connections might tie up your somaxconn
-quota of SYN_RCVD-state connections. Until the kernel times out
-these embryonic connections, no other connections will be accepted,
-and it will appear as if the server has died.
-
-The default value for somaxconn in Digital UNIX V4.0 will be quite
-a bit larger than it has been in previous versions (we inherited
-this default from 4.3BSD).
-
-Digital UNIX V4.0 includes some other performance-related changes
-that significantly improve its maximum HTTP connection rate. However,
-we've been using V3.2C systems to front-end for altavista.digital.com
-with no obvious performance bottlenecks at the millions-of-hits-per-day
-level.
-
-We have some Webstone performance results available at
- http://www.digital.com/info/alphaserver/news/webff.html
-
-<em>[The document referenced above is no longer at that URL -- Ed.]</em>
-
-I'm not sure if these were done using V4.0 or an earlier version
-of Digital UNIX, although I suspect they were done using a test
-version of V4.0.
-
--Jeff
-
-----------------------------------------------------------------------------
-
-From mogul@pa.dec.com (Jeffrey Mogul)
-Organization DEC Western Research
-Date 31 May 1996 21:01:01 GMT
-Newsgroups <a
-href="news:comp.unix.osf.osf1">comp.unix.osf.osf1</a>
-Message-ID &lt;4onmmd$mmd@usenet.pa.dec.com&gt;
-Subject Digital UNIX V3.2C Internet tuning patch info
-
-----------------------------------------------------------------------------
-
-Something that probably few people are aware of is that Digital
-has a patch kit available for Digital UNIX V3.2C that may improve
-Internet performance, especially for busy web servers.
-
-This patch kit is one way to increase the value of somaxconn,
-which I discussed in a message here a day or two ago.
-
-I've included in this message the revised README file for this
-patch kit below. Note that the original README file in the patch
-kit itself may be an earlier version; I'm told that the version
-below is the right one.
-
-Sorry, this patch kit is NOT available for other versions of Digital
-UNIX. Most (but not quite all) of these changes also made it into V4.0,
-so the description of the various tuning parameters in this README
-file might be useful to people running V4.0 systems.
-
-This patch kit does not appear to be available (yet?) from
- <a
-href="http://www.service.digital.com/html/patch_service.html">http://www.service.digital.com/html/patch_service.html</a>
-so I guess you'll have to call Digital's Customer Support to get it.
-
--Jeff
-
-DESCRIPTION: Digital UNIX Network tuning patch
-
- Patch ID: OSF350-146
-
- SUPERSEDED PATCHES: OSF350-151, OSF350-158
-
- This set of files improves the performance of the network
- subsystem on a system being used as a web server. There are
- additional tunable parameters included here, to be used
- cautiously by an informed system administrator.
-
-TUNING
-
- To tune the web server, the number of simultaneous socket
- connection requests are limited by:
-
- somaxconn Sets the maximum number of pending requests
- allowed to wait on a listening socket. The
- default value in Digital UNIX V3.2 is 8.
- This patch kit increases the default to 1024,
- which matches the value in Digital UNIX V4.0.
-
- sominconn Sets the minimum number of pending connections
- allowed on a listening socket. When a user
- process calls listen with a backlog less
- than sominconn, the backlog will be set to
- sominconn. sominconn overrides somaxconn.
- The default value is 1.
-
- The effectiveness of tuning these parameters can be monitored by
- the sobacklog variables available in the kernel:
-
- sobacklog_hiwat Tracks the maximum pending requests to any
- socket. The initial value is 0.
-
- sobacklog_drops Tracks the number of drops exceeding the
- socket set backlog limit. The initial
- value is 0.
-
- somaxconn_drops Tracks the number of drops exceeding the
- somaxconn limit. When sominconn is larger
- than somaxconn, tracks the number of drops
- exceeding sominconn. The initial value is 0.
-
- TCP timer parameters also affect performance. Tuning the following
- require some knowledge of the characteristics of the network.
-
- tcp_msl Sets the tcp maximum segment lifetime.
- This is the maximum lifetime in half
- seconds that a packet can be in transit
- on the network. This value, when doubled,
- is the length of time a connection remains
- in the TIME_WAIT state after a incoming
- close request is processed. The unit is
- specified in 1/2 seconds, the initial
- value is 60.
-
- tcp_rexmit_interval_min
- Sets the minimum TCP retransmit interval.
- For some WAN networks the default value may
- be too short, causing unnecessary duplicate
- packets to be sent. The unit is specified
- in 1/2 seconds, the initial value is 1.
-
- tcp_keepinit This is the amount of time a partially
- established connection will sit on the listen
- queue before timing out (<em>e.g.</em>, if a client
- sends a SYN but never answers our SYN/ACK).
- Partially established connections tie up slots
- on the listen queue. If the queue starts to
- fill with connections in SYN_RCVD state,
- tcp_keepinit can be decreased to make those
- partial connects time out sooner. This should
- be used with caution, since there might be
- legitimate clients that are taking a while
- to respond to SYN/ACK. The unit is specified
- in 1/2 seconds, the default value is 150
- (ie. 75 seconds).
-
- The hashlist size for the TCP inpcb lookup table is regulated by:
-
- tcbhashsize The number of hash buckets used for the
- TCP connection table used in the kernel.
- The initial value is 32. For best results,
- should be specified as a power of 2. For
- busy Web servers, set this to 2048 or more.
-
- The hashlist size for the interface alias table is regulated by:
-
- inifaddr_hsize The number of hash buckets used for the
- interface alias table used in the kernel.
- The initial value is 32. For best results,
- should be specified as a power of 2.
-
- ipport_userreserved The maximum number of concurrent non-reserved,
- dynamically allocated ports. Default range
- is 1025-5000. The maximum value is 65535.
- This limits the numer of times you can
- simultaneously telnet or ftp out to connect
- to other systems.
-
- tcpnodelack Don't delay acknowledging TCP data; this
- can sometimes improve performance of locally
- run CAD packages. Default is value is 0,
- the enabled value is 1.
-
- Digital UNIX version:
-
- V3.2C
-Feature V3.2C patch V4.0
-======= ===== ===== ====
-somaxconn X X X
-sominconn - X X
-sobacklog_hiwat - X -
-sobacklog_drops - X -
-somaxconn_drops - X -
-tcpnodelack X X X
-tcp_keepidle X X X
-tcp_keepintvl X X X
-tcp_keepcnt - X X
-tcp_keepinit - X X
-TCP keepalive per-socket - - X
-tcp_msl - X -
-tcp_rexmit_interval_min - X -
-TCP inpcb hashing - X X
-tcbhashsize - X X
-interface alias hashing - X X
-inifaddr_hsize - X X
-ipport_userreserved - X -
-sysconfig -q inet - - X
-sysconfig -q socket - - X
-
-</pre>
- <hr />
-
- <h3 align="CENTER">Apache HTTP Server Version 1.3</h3>
- <a href="./"><img src="../images/index.gif" alt="Index" /></a>
- <a href="../"><img src="../images/home.gif" alt="Home" /></a>
-
- </body>
-</html>
-
diff --git a/usr.sbin/httpd/htdocs/manual/misc/perf-hp.html b/usr.sbin/httpd/htdocs/manual/misc/perf-hp.html
deleted file mode 100644
index 8a2fb5cebec..00000000000
--- a/usr.sbin/httpd/htdocs/manual/misc/perf-hp.html
+++ /dev/null
@@ -1,107 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <meta name="generator" content="HTML Tidy, see www.w3.org" />
-
- <title>Running a High-Performance Web Server on HPUX</title>
- </head>
- <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
-
- <body bgcolor="#ffffff" text="#000000" link="#0000ff"
- vlink="#000080" alink="#ff0000">
- <a id="initial" name="initial">&nbsp;</a>
- <div align="CENTER">
- <img src="../images/sub.gif" alt="[APACHE DOCUMENTATION]" />
-
- <h3>Apache HTTP Server Version 1.3</h3>
- </div>
-
-
-
- <h1 align="center">Running a High-Performance Web Server for
- HPUX</h1>
-<pre>
-Date: Wed, 05 Nov 1997 16:59:34 -0800
-From: Rick Jones &lt;<a
-href="mailto:raj@cup.hp.com">raj@cup.hp.com</a>&gt;
-Reply-To: raj@cup.hp.com
-Organization: Network Performance
-Subject: HP-UX tuning tips
-</pre>
- Here are some tuning tips for HP-UX to add to the tuning page.
-
- <p>For HP-UX 9.X: Upgrade to 10.20<br />
- For HP-UX 10.[00|01|10]: Upgrade to 10.20</p>
-
- <p>For HP-UX 10.20:</p>
-
- <p>Install the latest cumulative ARPA Transport Patch. This
- will allow you to configure the size of the TCP connection
- lookup hash table. The default is 256 buckets and must be set
- to a power of two. This is accomplished with adb against the
- *disc* image of the kernel. The variable name is tcp_hash_size.
- Notice that it's critically important that you use "W" to write
- a 32 bit quantity, not "w" to write a 16 bit value when
- patching the disc image because the tcp_hash_size variable is a
- 32 bit quantity.</p>
-
- <p>How to pick the value? Examine the output of <a
- href="ftp://ftp.cup.hp.com/dist/networking/tools/connhist">ftp://ftp.cup.hp.com/dist/networking/tools/connhist</a>
- and see how many total TCP connections exist on the system. You
- probably want that number divided by the hash table size to be
- reasonably small, say less than 10. Folks can look at HP's
- SPECweb96 disclosures for some common settings. These can be
- found at <a
- href="http://www.specbench.org/">http://www.specbench.org/</a>.
- If an HP-UX system was performing at 1000 SPECweb96 connections
- per second, the TIME_WAIT time of 60 seconds would mean 60,000
- TCP "connections" being tracked.</p>
-
- <p>Folks can check their listen queue depths with <a
- href="ftp://ftp.cup.hp.com/dist/networking/misc/listenq">ftp://ftp.cup.hp.com/dist/networking/misc/listenq</a>.</p>
-
- <p>If folks are running Apache on a PA-8000 based system, they
- should consider "chatr'ing" the Apache executable to have a
- large page size. This would be "chatr +pi L &lt;BINARY&gt;."
- The GID of the running executable must have MLOCK privileges.
- Setprivgrp(1m) should be consulted for assigning MLOCK. The
- change can be validated by running Glance and examining the
- memory regions of the server(s) to make sure that they show a
- non-trivial fraction of the text segment being locked.</p>
-
- <p>If folks are running Apache on MP systems, they might
- consider writing a small program that uses mpctl() to bind
- processes to processors. A simple pid % numcpu algorithm is
- probably sufficient. This might even go into the source
- code.</p>
-
- <p>If folks are concerned about the number of FIN_WAIT_2
- connections, they can use nettune to shrink the value of
- tcp_keepstart. However, they should be careful there -
- certainly do not make it less than oh two to four minutes. If
- tcp_hash_size has been set well, it is probably OK to let the
- FIN_WAIT_2's take longer to timeout (perhaps even the default
- two hours) - they will not on average have a big impact on
- performance.</p>
-
- <p>There are other things that could go into the code base, but
- that might be left for another email. Feel free to drop me a
- message if you or others are interested.</p>
-
- <p>sincerely,</p>
-
- <p>rick jones<br />
- <a
- href="http://www.cup.hp.com/netperf/NetperfPage.html">http://www.cup.hp.com/netperf/NetperfPage.html</a>
- <hr />
-
- <h3 align="CENTER">Apache HTTP Server Version 1.3</h3>
- <a href="./"><img src="../images/index.gif" alt="Index" /></a>
- <a href="../"><img src="../images/home.gif" alt="Home" /></a>
-
- </p>
- </body>
-</html>
-