|
Allow us to change the HTTP thread queue implementation
|
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. |
|
| Default value: 0 |
| UI equivalent: None
|
| Applies to: Servers |
| Documented in: IBM Technote 21201715 |
| Weblink: IBM Technote 21201715 |
| Key submitted from: Bastian Wieczorek |
