|
|
|
The FairCom DB SNAPSHOT feature provides a wealth of performance and tuning information, including function call timing. Profiling FairCom DB function calls can provide a very precise tuning method for looking at performance issues. Consider an application that spends an inordinate amount of time processing GTVREC() calls; 61% of the total FairCom DB call time is spent in GTVREC():
function count elapsed average % of tot
GTVREC 1562390 47368 0.0303 61%
TRANEND 230398 13092 0.0568 17%
DELVREC 883241 11051 0.0125 14%
EQLVREC 998513 4251 0.0043 6%
TRANBEG 230399 661 0.0029 1%
LTVREC 230445 489 0.0021 1%
Here's a suggestion that can improve performance in this situation. There may be GTVREC() calls that can be replaced with NXTVREC(). For example, the function monitor log showed the following sequence of calls:
TRANBEG
EQLVREC ../CURRENTFILESCANPAGES/Listings.idx
DELVREC ../CURRENTFILESCANPAGES/Listings.dat
GETCURK ../CURRENTFILESCANPAGES/Listings.idx M#1
GTVREC ../CURRENTFILESCANPAGES/Listings.idx M#1
TRANEND
In this case, if you reading the key of the record that you just deleted and then reading the next record you could simply call NXTVREC() like this instead:
TRANBEG
EQLVREC ../CURRENTFILESCANPAGES/Listings.idx
DELVREC ../CURRENTFILESCANPAGES/Listings.dat
NXTVREC ../CURRENTFILESCANPAGES/Listings.idx M#1
TRANEND
Here's why we suggest you use NXTVREC() instead of GTVREC() when possible:
GTVREC() does a full key search starting from the root node. NXTVREC() already knows which leaf node corresponds to your current ISAM position (that was set when you called EQLVREC()), and so it goes directly to that node and searches from there for the next key value.
What can happen in some cases is that leaf nodes become empty as keys were deleted, and before the delete node thread had removed them from the index tree, the application made a number of calls to GTVREC() which visited those nodes and added them to the delete node queue again. With these simple code changes above, no duplicate entries will be added to the delete node queue, however, there is slight overhead in performing the tree search and checking if the entry is already in the delete node queue. We expect NXTVREC() to be more efficient than GTVREC() as it starts at the current leaf node.
