IBM Support

In Release 6, Web-Triggered Agents Take Longer to Complete when Maintaining Unread Marks

Technote (FAQ)


Question

After you upgrade a Lotus Domino server from Release 5 to Release 6, you find that Web-triggered agents run noticeably slower. Agents affected include LotusScript and Java agents triggered using WebQueryOpen or WebQuerySave, or those triggered by the OpenAgent URL command. You are more likely to see a performance impact if running Web agents concurrently (Server document -> Internet Protocols tab -> Domino Web Engine tab -> "Run Web agents concurrently").

Answer

Domino 6 is working as designed. Enhancements to the underlying unread functionality introduced in Domino 6 require additional system resources beyond what R5 required. This is as designed and is a consequence of upgrading the internal format of the unread table storage. This additional overhead can affect the performance of Web-triggered agents that access that database. For some databases, unread marks are not necessary. If you disable the property to maintain unread marks, you can avoid the overhead and improve Web-triggered agent performance.
To disable maintaining unread marks, open each database that the affected agent accesses and perform the following steps:

1. Select File -> Database -> Properties and go to the Advanced tab.
2. Select "Don't Maintain Unread Marks."
3. Run the Compact command with the -c parameter by issuing the following command on the server console:

    Load compact –c <db name>
    Tip: You can also run the Compact server task with the -u or -U option to enable or disable this property and then compact.

For more information on this property, refer to the Domino Designer Help topic "Properties that improve database performance."

Additional diagnosis details
By inserting print statements at the beginning and end of an agent and enabling AgentThreadDebug=1, you can determine if an agent is being impacted by unread mark overhead. On the server console, you will see a delay between the last print statement that the agent outputs and the time the agent terminates, such as follows:

[1014:0023-0DA0] 07/14/2005 09:20:26 PM *** Agent Start: agent "WebQueryOpen" in "D:\notes\data\testdb.nsf" (thread [1014:0023-0DA0])
[1014:0023-0DA0] 07/14/2005 09:20:34 PM Agent message: Starting Execution
[1014:0023-0DA0] 07/14/2005 09:20:34 PM Agent message: Completed Execution
[1014:0023-0DA0] 07/14/2005 09:20:47 PM *** Agent Completed: agent "WebQueryOpen" in "D:\notes\data\testdb.nsf" (thread [1014:0023-0DA0])

When a LotusScript or Java agent terminates, it synchronizes any changes that it may have made to the unread marks in all of the databases that it has opened during its execution. This process is synchronized against concurrent operations by a semaphore, so if several copies of an agent are running concurrently, other agents have to wait if another is already terminating.

It is possible for this situation to occur with agents being run by the Agent Manager task; however, it is most likely to be observed for Web-triggered agents because a fairly high degree of concurrency is needed for this synchronization to cause a noticeable delay in agent execution time.

If you run NSD during the agent executive, you can see that one or both of the thread stacks shown below are present. (Note that the time that the NSD is taken impacts whether or not you see these thread stacks. You may have to take several NSDs to capture them at the right time.)

############################################################
### thread 39/151: [ nhttp:01c0:0f54]
### FP=51dd3dc8, PC=77f82870, SP=51dd3da4, stkbase=51ce0000, stksize=262144
############################################################
[ 1] 0x77f82870 ntdll.RtlAdjustPrivilege+143 (1d54,3a98,0,600a7dd7)
[ 2] 0x7c57b3db KERNEL32.CreateProcessW+393 (1b1,4b201170,60c31f44,0)
@[ 3] 0x600011a8 nnotes._OSLockSemInt@8+216 (4b201170,1,51dd3e70,62652a0b)
@[ 4] 0x600010be nnotes._OSLockSem@4+14 (4b201170,5a2b0236,5a2b0190,0)
@[ 5] 0x62652a0b nlsxbe.ANDatabase::ANDCloseThread+203 (0,5a2b0190,51dd4348,62648812)
@[ 6] 0x626489da nlsxbe.ANDatabase::ANDClose+202 (5a2b0190,51dd3ed4,62659e22,1)
@[ 7] 0x6264816b nlsxbe.ANDatabase::`scalar deleting destructor'+11 (1,51dd0002,5a2b0190,51dd4348)
@[ 8] 0x62659e22 nlsxbe.ANotes::ANDecRefCount+370 (1,51dd4364,5ab8cf9c,0)
@[ 9] 0x626428a2 nlsxbe._ANCLASSCONTROL@16+194 (5ab7b720,106,51dd4348,0)
@[10] 0x62643309 nlsxbe._tag_NotesADTControl::ClassControl+25 (5a2b01bc,5ab7b720,106,51dd4348)
@[11] 0x600590b2 nnotes.LSsInstance::AdtCallBack+226 (5ab7b720,626427e0,106,5ab8cf80)
@[12] 0x60069241 nnotes.LScObjCli::CallAdtProc+145 (5ab8cf40,106,0,5dc72b34)
@[13] 0x6009119b nnotes.LScObjCli::DropDead+27 (5ab8cf40,5dc724f0,51dd4438,6010b803)
@[14] 0x6008c3c9 nnotes.LSsThread::DeleteVar+425 (5ad4f048,5dc72b34,5e3f636c,51dd4444)
@[15] 0x6010b803 nnotes.LSsThread::DeleteModuleLocals+227 (5e3f636c,5e20f358,5e3f1264,ffffff00)
@[16] 0x60021523 nnotes.LSsThread::NRun+963 (5ad4f048,5ad4f048,5e20f358,51dd4544)
@[17] 0x60023276 nnotes.LSsThread::Run+182 (5ad4f048,5ab7b720,5ad4f048,5946b518)

############################################################
### thread 132/151: [ nhttp:01c0:0834]
### FP=57ad36b8, PC=6060878e, SP=57ad3638, stkbase=579e0000, stksize=262144
############################################################
@[ 1] 0x6060878e nnotes._LocateID@28+574 (27140b50,bbdda,57ad3818,57ad3810)
@[ 2] 0x60606b37 nnotes._IDHInsert@12+231 (19de,bbdda,0,27140b50)
@[ 3] 0x60609fdc nnotes._IDHInsertRange@16+92 (19de,bbdda,bbdda,0)
@[ 4] 0x60602fc1 nnotes._IDInsertRange@16+97 (19de,bbdda,bbdda,0)
@[ 5] 0x6018726c nnotes._IDInsertTable@8+892 (19de,2639,179af06e,2987)
@[ 6] 0x60605c4d nnotes._IDTableDifferences@20+1549 (2639,2987,57ad3d74,57ad3d78)
@[ 7] 0x608583e0 nnotes._DbSetUnreadNoteTable@24+800 (57ad3e18,17996b60,21,1)
@[ 8] 0x6077b4d1 nnotes._iNSFDbSetUnreadNoteTable@24+145 (0,17996b60,21,1)
@[ 9] 0x6078587c nnotes._ApplyDiffsToUnreadList+188 (57ad3e18,1,0,58d1a9b4)
@[10] 0x60785770 nnotes._iNSFDbDisassociateUnreadList@4+32 (57ad3e18,58d1a9b4,179968e8,19ff0e8)
@[11] 0x60759a5d nnotes._NSFDbDisassociateUnreadList@4+77 (0,58d23dfe,58d23d58,0)
@[12] 0x62652a62 nlsxbe.ANDatabase::ANDCloseThread+290 (0,58d23d58,57ad4348,62648812)
@[13] 0x626489da nlsxbe.ANDatabase::ANDClose+202 (58d23d58,57ad3ed4,62659e22,1)
@[14] 0x6264816b nlsxbe.ANDatabase::`scalar deleting destructor'+11 (1,57ad0002,58d23d58,57ad4348)
@[15] 0x62659e22 nlsxbe.ANotes::ANDecRefCount+370 (1,57ad4364,5caed654,0)
@[16] 0x626428a2 nlsxbe._ANCLASSCONTROL@16+194 (5c6feb98,106,57ad4348,0)
@[17] 0x62643309 nlsxbe._tag_NotesADTControl::ClassControl+25 (58d23d84,5c6feb98,106,57ad4348)
@[18] 0x600590b2 nnotes.LSsInstance::AdtCallBack+226 (5c6feb98,626427e0,106,5caed638)
@[19] 0x60069241 nnotes.LScObjCli::CallAdtProc+145 (5caed5f8,106,0,5e54cb54)
@[20] 0x6009119b nnotes.LScObjCli::DropDead+27 (5caed5f8,5e3567b0,57ad4438,6010b803)
@[21] 0x6008c3c9 nnotes.LSsThread::DeleteVar+425 (5cc93e28,5e54cb54,5e581b0c,57ad4444)
@[22] 0x6010b803 nnotes.LSsThread::DeleteModuleLocals+227 (5e581b0c,5da578a0,5e581264,ffffff00)
@[23] 0x60021523 nnotes.LSsThread::NRun+963 (5cc93e28,5cc93e28,5da578a0,57ad4544)
@[24] 0x60023276 nnotes.LSsThread::Run+182 (5cc93e28,5c6feb98,5cc93e28,5a1813f4)

In the above threads, the second one is performing its unread mark synchronization, while the first one is waiting for it to complete (indicated by the OSLockSem and OSLockSemInt calls).

Related information

Cross reference information
Segment Product Component Platform Version Edition
Messaging Applications Lotus End of Support Products Lotus Domino Server Platform Independent 6.5, 6.0

Document information

More support for: Lotus End of Support Products
Lotus Domino Designer

Software version: 6.0, 6.5

Operating system(s): AIX, HP-UX, IBM i, Linux, Solaris, Windows, z/OS

Reference #: 1212520

Modified date: 25 July 2005


Translate this page: