|
|
| (9 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| == LOTUS TRAVELER THREAD POOLS ==
| | Page moved to [[Lotus Traveler: Tuning English]] |
| | |
| === Description ===
| |
| | |
| Lotus Notes Traveler has four thread pools that can be tuned:
| |
| | |
| * '''Prime sync threads''' - Determine if changes to user mail files need to be synchronized to user devices.
| |
| * '''Device sync thread'''s - Synchronize data between Domino mail servers and user devices.
| |
| * '''Worker threads''' - Used internally in the device synchronization process.
| |
| * '''HTTP threads''' - Used by the HTTP task, one per HTTP connection.
| |
| | |
| === Default Values ===
| |
| | |
| Variables at file ''Domino data directory\traveler\cfg\NTSConfig.xml''.
| |
| | |
| | |
| {| border="1"
| |
| |
| |
| '''Thread pool name'''
| |
| |
| |
| '''Default Value'''
| |
| |-
| |
| |
| |
| '''TSS_PRIMESYNC_THREADS'''
| |
| |
| |
| 10
| |
| |-
| |
| |
| |
| '''TSS_SYNC_THREADS'''
| |
| |
| |
| 50
| |
| |-
| |
| |
| |
| '''WORKER_THREADS'''
| |
| |
| |
| 100 (should always be double the TSS_SYNC_THREADS value)
| |
| |-
| |
| |
| |
| '''HTTP Threads'''
| |
| |
| |
| * 100 on Windows 32-bit machines
| |
| * 400 on Windows 64-bit machines)
| |
| |}
| |
| | |
| | |
| The following are general guidelines for the relationships between the number of threads in each of the thread pools.
| |
| | |
| * Prime sync threads should be much less than the number of device sync threads; normally the prime sync default of 10 threads should be adequate.
| |
| * Worker threads should be double the number of device sync threads.
| |
| * HTTP threads should be 1.2 times either the number of device sync threads or the number of ActiveSync devices, whichever is larger.
| |
| | |
| | |
| === Statistics ===
| |
| | |
| The first set of statistics is the device synchronization GetThreadDelayTime histogram, where you can see if there is a long delay before a device synchronization thread is allocated. This is an example of a device synchronization thread histogram:
| |
| | |
| * ThreadPool.GetThreadDelayTime.DS.00-02 = 571071
| |
| * ThreadPool.GetThreadDelayTime.DS.02-05 = 45
| |
| * ThreadPool.GetThreadDelayTime.DS.05-10 = 29
| |
| * ThreadPool.GetThreadDelayTime.DS.10-Inf = 17
| |
| | |
| In this example the first line indicates that the majority of the device synchronization starts in the 0 to 2 second range. This implies that the current device thread count is sufficient for the load.
| |
| | |
| The second set of statistics is the number of device synchronizations that have finished with various return codes (DeviceSync.Count.xxx). The return codes are:
| |
| | |
| * 200 - Successful
| |
| * 408 - Device did not respond before the server terminated the session
| |
| * 409 - Device started a new session which caused this session to be terminated
| |
| * 500 - Unknown Error
| |
| * 503 - Server Busy
| |
| | |
| DeviceSync.Count.503 shows the number of synchronizations that were not allowed to start and were ultimately aborted because a device synchronization thread could not be allocated to run the synchronization. This value should be much smaller than the DeviceSync.Count.200 value, which shows the number of synchronizations that have finished with a return code of 200 (Successful). If the DeviceSync.Count.503 value is too high, you should increase the number of device synchronization threads, which should reduce the occurrence of synchronizations that result in a server busy response.
| |
| | |
| The following is an example of the DeviceSync.Count stats. In this case, the ratio of 503 results (4) to 200 results (43427) is very small, which indicates there is no need for additional device synchronization threads.
| |
| | |
| * DeviceSync.Count.200 = 43427
| |
| * DeviceSync.Count.408 = 199
| |
| * DeviceSync.Count.409 = 44
| |
| * DeviceSync.Count.500 = 5
| |
| * DeviceSync.Count.503 = 4
| |
| | |
| | |
| === References ===
| |
| | |
| [http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=%2Fcom.ibm.help.lnt851.doc%2FTuning_performance_of_the_server.html Lotus Traveler Tuning performance of the server] | |
| | |
| == Cache User Info - HTTP Maximum Cached Users - 64 bits only ==
| |
| | |
| To optimize the response time keeps Domino design elements in memory.
| |
| | |
| {| border="1"
| |
| |
| |
| '''Tune'''
| |
| |
| |
| To change the parameters of Web Cache, Open the server document and go
| |
| | |
| '''Internet Protocols → Domino Web Engine → Memory Caches.'''
| |
| | |
| and change the field value
| |
| | |
| {| border="1"
| |
| |
| |
| '''Field'''
| |
| |
| |
| '''Description'''
| |
| |-
| |
| |
| |
| '''Maximum cached users'''
| |
| |
| |
| Enter the number of users to cache. The default is 64.
| |
| After a user successfully authenticates with a server, Domino stores in memory the user's name, password, and the list of groups to which the user belongs. Use this field to increase the number of users for whom Domino stores this information.
| |
| |}
| |
| | |
| | |
| |-
| |
| |
| |
| '''Statistics'''
| |
| |
| |
| * Push.Devices.Total
| |
| |-
| |
| |
| |
| '''Interpretation'''
| |
| |
| |
| * Push.Devices.Total = 2455
| |
| |-
| |
| |
| |
| '''Reference'''
| |
| |
| |
| | |
| |}
| |
| | |
| === Example ===
| |
| | |
| To find out if you need to change this parameter, run the following command
| |
| | |
| > Show stat domino.cache.user*
| |
| Domino.Cache.User Cache.Count = 68
| |
| Domino.Cache.User Cache.DisplaceRate = 0
| |
| Domino.Cache.User Cache.HitRate = 73.258795221749
| |
| Domino.Cache.User Cache.MaxSize = 64
| |
| | |
| | |
| Observing these numbers we can deduce that the value of elements ('''Count''') has reached the maximum ('''MaxSize'''), so elements in this cache are discarded (''' DisplaceRate''').
| |
| | |
| The optimal value for the'''Hitrate''' is near 100%, and'''DisplaceRate''' is 0%. Increasing the value of the field'''Maximum cached designs''' improves response-time.
| |
