Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-14195

Reduce set_last_error calls in API_INIT

    • Storage Engines
    • 3
    • StorEng - 2025-02-28, StorEng - 2025-03-14

      As part of PM-3810 and WT-13866, we have introduced a performance regression shown within BF-36693. The performance regression is due the number of calls calling set last error within each session API call. Currently, we call the set_last_error function to return the session error info structure to the default state before performing the actual session API work. This was done because of the need to have error state clean before we start tracking errors within WiredTiger.

      Evidence
      Through adding a bunch of statistics I was able to validate that calling set_last_error causes majority of the performance regression within the BF. See here:

      The majority of the time spent within the calls is spent within serverStatus wiredTiger thread-yield set error 2 rate. This statistic refers to this code:

          if (fmt != NULL && strlen(fmt) == 0) {
              err_info->err_msg = WT_ERROR_INFO_EMPTY;
              WT_STAT_CONN_INCR(session, error_set_1);
          } else if (err == 0) {
              WT_ASSERT(session, fmt == NULL);
              err_info->err_msg = WT_ERROR_INFO_SUCCESS;
              WT_STAT_CONN_INCR(session, error_set_2);
          } else {
              WT_ASSERT(session, fmt != NULL);
              WT_VA_ARGS_BUF_FORMAT(session, &(err_info->err_msg_buf), fmt, false);
              err_info->err_msg = err_info->err_msg_buf.data;
              WT_STAT_CONN_INCR(session, error_set_3);
          }
      

      The second branch condition is evoked the most. This condition describes when we have set the session error info to the default state. This ticket aims to fix and reduce the need to call set_last_error.

            Assignee:
            jie.chen@mongodb.com Jie Chen
            Reporter:
            jie.chen@mongodb.com Jie Chen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: