SPR

Technote

Problem:
This issue was reported to Quality Engineering as SPR# NORK65PNF3 and has been
fixed in Domino 6.5.4 Fix Pack 1 (6.5.4.1) and Domino 6.5.5, and also in Domino
7.0. Refer to the Upgrade Central site for details about obtaining 6.5.4 Fix
Pack 1, 6.5.5, or 7.0.
Excerpt from the Lotus Domino Release 6.5.4 Fix Pack 1 and 6.5.5 fix list
(available at http://www.ibm.com/developerworks/lotus):

SPR# NORK65PNF3 - When moving from Domino 5.x to 6.x, the HTTP thread
management model was changed. With the 5.x model, each thread managed one
request at a time. In 6.x, the model was changed so that each thread could have
a queue of requests. With this change in 6.5.4 FP1, and 6.5.5, we are allowing
the option to change how threads process HTTP connections. The original R5.x
model or R6.x queue of requests model can be selected.

Use the following Notes.ini settings for these changes:

HTTPQueueMethod=0 - This setting is the default, and represents no change in
queueing from the R6.0 and above. The accept thread will evenly distributed
network connections to all worker threads using a round robin method.
Connections are assigned to a specific thread.
HTTPQueueMethod=1 - This setting will cause the accept thread to find the
worker thread that has the least number of network connections assigned to it
and assign the new network connection to that worker thread. It is still
possible that a new network connection may be assigned to a thread that is in
the process of processing a long running request. It is recommended but not
required that persistent connections are disabled when using this option to get
the maximum effect. This will limit the possible wait time if a new network
connection is queued to a thread that already is busy with other connections(s)
HTTPQueueMethod=2 - This setting will cause the accept thread to put the
incoming network connections on a queue from with the worker threads will pull
from. This is the same model as R5. It is also recommend but not required that
persistent connections be disabled when using this option to get the maximum
effect.

In general the best method to use will depend on the nature of applications
running on the server. If the mix of URL requests presented to the server run
very quickly then option 0 or 1 will be the best option. Option 1 performs a
little better then option 0 but at a slightly higher CPU cost so if URL
requests are CPU bound then option 1 may actually slow overall through put of
the server. The slowest option is option 2 with regard to overall server
throughput, however if the mix of URL requests include very long running
requests such as large uploads/downloads or URLs that run application code then
this may be the best option for the customer.

Additional Explanation:
Domino 6.x implements a new HTTP thread management model, or method to handle
HTTP requests, that differs from Domino R5. For example, a Domino server has
40 active HTTP threads on the system. Ten threads are busy running agents and
15 more are responding to other URL requests. When the next URL request is
received, Domino versions behave as described below.
Domino 6
A Domino 6 server uses a round-robin model to assign requests, so can assign
the request to the queue for one of the idle HTTP threads or one of the
currently working HTTP threads.

If the new request is assigned to one of the idle threads, Web users see no
noticeable delay. If the new request is assigned to a currently working HTTP
thread that is executing a long-running URL like a search agent, for instance,
the new URL request must wait for processing until the thread completes the
previous URL request. Therefore, the Web user can experience a delay.
This thread management implementation allows Domino to handle many more
requests with fewer active HTTP threads, thus avoiding excessive memory usage.
The drawback is a performance impact for environments where new, short URL
requests are queued behind lengthy URL requests like agents.
Domino R5
The new URL request is assigned to a queue from which the idle HTTP threads
draw their work. As noted above, this thread model can require more memory to
implement, plus the overall server throughput can be slower than the Domino 6
model.
Workaround for earlier 6.x releases:
To work around the problem in earlier 6.x releases, you can edit the Internet
Protocols -> HTTP tab of the Server document to set the "Number of Active
threads" equal to the "Maximum number of concurrent network sessions." This
equal setting gives the server a one-to-one (1:1) ratio. Next, raise the
Listen queue size on the same tab to help buffer these requests.

If the performance issue still happens after setting this 1:1 ratio, then the
performance slowdown may not be due to the new threading model and
investigations should continue. More >