craig_welton
Legendary Poster
Came across an interesting discovery this week ...
While troubleshooting a client's E900 performance issue (compared to their live 8.10 install), we discovered that for every fetch of F0111, F0115 or F0116, the system was running a set of BSFNs referring to ABDP (Address Book Data Privacy). One of these BSFNs was actually performing a select/fetch on F0101 which ended up making a particular UBE way slower than it was in 8.10 (there were other reasons as well, see Brother Of Karamazov's post regarding 2008 Server's magic button).
Now, this client does not have AB Privacy turned on in F0009 (or so we thought). The field GCGFCF1 is actually set to blank. The problem is that the AB Privacy functions expect the value to be '0' when it's turned off. Once you use the P0000 app to view the AB constants and save the data with the unchecked box, the value should be set to '0'. Once this was done, the extra F0101 select/fetch was not done and performance improved greatly.
This client recieved this "feature" through ESU JL16882. It delivers the new function and builds triggers on F0111, F0115 and F0116 to call them. From what I can tell based on other clients data in F0009, if you install this ESU you may see this performance hit as your system will think AB privacy is enabled because that column is set to blank.
On a side note ... even if you have data privacy turned off, your system will now run a set of BSFNs for every F0111, F0115 and F0116 record that is fetched. In one example, a report that read 1500 F0101 and F0111 records (via a join) ran in 22 seconds. 8 of those seconds was spent in the BSFNs called by the trigger that just figured out that the privacy feature is off. I realize this is a worst case scenario, but that's a significant amount of overhead.
just sayin,
Craig
While troubleshooting a client's E900 performance issue (compared to their live 8.10 install), we discovered that for every fetch of F0111, F0115 or F0116, the system was running a set of BSFNs referring to ABDP (Address Book Data Privacy). One of these BSFNs was actually performing a select/fetch on F0101 which ended up making a particular UBE way slower than it was in 8.10 (there were other reasons as well, see Brother Of Karamazov's post regarding 2008 Server's magic button).
Now, this client does not have AB Privacy turned on in F0009 (or so we thought). The field GCGFCF1 is actually set to blank. The problem is that the AB Privacy functions expect the value to be '0' when it's turned off. Once you use the P0000 app to view the AB constants and save the data with the unchecked box, the value should be set to '0'. Once this was done, the extra F0101 select/fetch was not done and performance improved greatly.
This client recieved this "feature" through ESU JL16882. It delivers the new function and builds triggers on F0111, F0115 and F0116 to call them. From what I can tell based on other clients data in F0009, if you install this ESU you may see this performance hit as your system will think AB privacy is enabled because that column is set to blank.
On a side note ... even if you have data privacy turned off, your system will now run a set of BSFNs for every F0111, F0115 and F0116 record that is fetched. In one example, a report that read 1500 F0101 and F0111 records (via a join) ran in 22 seconds. 8 of those seconds was spent in the BSFNs called by the trigger that just figured out that the privacy feature is off. I realize this is a worst case scenario, but that's a significant amount of overhead.
just sayin,
Craig
