Explanation:
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.
Valid Values are:
0 - This setting is the default in versions prior to 8.5.1, 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. This means no change in queueing from the R6.0 and above
versions.
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)
2 - This setting is the default for 8.5.1 and later versions, changed due to new use cases. This setting will cause the accept thread to put the incoming network
connections on a central 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 the
this may be the best option for the customer.
The DOMINO HTTP SERVER DOES NOT SUPPORT RECURSIVE REQUESTS. IF HTTPQueueMethod
is set to 2 it is possible to deadlock the server. If one does recursive
requests then one may run into a deadlock problem. If all threads are
processing request 1 and all threads then make a recursive request the server
will dead lock.
Applies to:
Servers
Default Value:
0
2, beginning with Domino 8.5.1
UI equivalent:
None, although you can specify this setting in the NOTES.INI Settings tab of the Configuration Settings document in the Domino Directory.
Syntax:
HTTPQueueMethod=Value
Available since:
Lotus Notes/Domino 6.5.4 FP1
Obsolete since:
Lotus Notes/Domino x.x.x