Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6150

Speed up connection speed by moving creation of THD to new thread

Details

    • 10.1.6-2

    Description

      One major bottleneck for creating a new connection is that THD is created in the thread that is handing all connections.

      The fix for this is to move THD creation from the connection thread to the new thread that will handle queries.

      Attachments

        1. bb_fast_connect.ods
          60 kB
          Axel Schwenke
        2. MDEV-6150.ods
          89 kB
          Axel Schwenke
        3. my.cnf
          1 kB
          Axel Schwenke

        Issue Links

          Activity

            axel Axel Schwenke added a comment - - edited

            <montywi> XL: I update the bb-fast-connect tree in git; This is after serg's review
            <montywi> so I only need you to verify that things are same or better than normal 10.1 for connect tests and I can push
            <XL> montywi: I see
            <montywi> on my machine, having all threads in the thread cache gives a 5% speed increase; Having no thread cache was about the same
            <montywi> this was when running 32 perl processes on the same machine to connect, do a query and disconnect
            <montywi> doing this with a threaded benchmark should hopefully show a bigger speed increase

            axel Axel Schwenke added a comment - - edited <montywi> XL: I update the bb-fast-connect tree in git; This is after serg's review <montywi> so I only need you to verify that things are same or better than normal 10.1 for connect tests and I can push <XL> montywi: I see <montywi> on my machine, having all threads in the thread cache gives a 5% speed increase; Having no thread cache was about the same <montywi> this was when running 32 perl processes on the same machine to connect, do a query and disconnect <montywi> doing this with a threaded benchmark should hopefully show a bigger speed increase

            Pushed to bb-fast-connect tree for testing.

            monty Michael Widenius added a comment - Pushed to bb-fast-connect tree for testing.
            axel Axel Schwenke added a comment -

            Results from a short benchmark. I tested 3 scenarios

            1. standard sysbench OLTP readonly (1 connection per client thread that is reused)
            2. sysbench OLTP readonly, reconnection for each transaction
            3. simple workload: connect; select 1 from dual; disconnect

            The last scenario shows advantages for the bb_fast_connect tree. The other however give better results with vanilla 10.1.

            Benchmark was run on lizard2 (Intel, 32 cores, 64 threads). Huge thread pool was configured.

            axel Axel Schwenke added a comment - Results from a short benchmark. I tested 3 scenarios standard sysbench OLTP readonly (1 connection per client thread that is reused) sysbench OLTP readonly, reconnection for each transaction simple workload: connect; select 1 from dual; disconnect The last scenario shows advantages for the bb_fast_connect tree. The other however give better results with vanilla 10.1. Benchmark was run on lizard2 (Intel, 32 cores, 64 threads). Huge thread pool was configured.

            Pushed to 10.2.
            Speed up for connections are up to 40% when there is a lot of connections threads and the thread pool is 16 or higher.

            monty Michael Widenius added a comment - Pushed to 10.2. Speed up for connections are up to 40% when there is a lot of connections threads and the thread pool is 16 or higher.
            axel Axel Schwenke added a comment -

            Re-opened for benchmarking the effects of the change

            axel Axel Schwenke added a comment - Re-opened for benchmarking the effects of the change

            People

              axel Axel Schwenke
              monty Michael Widenius
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.