connpool: make call() execute faster
#10598
Comments
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Sep 25, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower than possible because only one active instance was needed to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. @TarantoolBot document Title: Experimental.connpool: new `filter()`, `call()` mode names The `connpool.filter()` options got new modes: - `alive` can be used to filter out only active connections matching other requirements. - The default mode is now named `any` (used by default when the mode is nil). It can be used to ignore instance status completely. - Other modes remained the same. The `connpool.call()` default filtering mode has now got a name `alive` (the mode is used if the mode is `nil`). It means "any alive instance". Other candidate filters for call execution remained the same. The `connpool.call()` function will now wait for any available instance matching the requirements in case of the `alive/ro/rw` modes. And it will try to connect to all of the matching instances if the mode is `prefer_ro`/`prefer_rw`. So if the modes are one of the `prefer_*` the function works slower in case there is at least one unavailable instance. Closes tarantool#10596 and tarantool#10598
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Sep 26, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower than possible because only one active instance was needed to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. @TarantoolBot document Title: Experimental.connpool: new `filter()`, `call()` mode names The `connpool.filter()` options got new modes: - `alive` can be used to filter out only active connections matching other requirements. - The default mode is now named `any` (used by default when the mode is nil). It can be used to ignore instance status completely. - Other modes remained the same. The `connpool.call()` default filtering mode has now got a name `alive` (the mode is used if the mode is `nil`). It means "any alive instance". Other candidate filters for call execution remained the same. The `connpool.call()` function will now wait for any available instance matching the requirements in case of the `alive/ro/rw` modes. And it will try to connect to all of the matching instances if the mode is `prefer_ro`/`prefer_rw`. So if the modes are one of the `prefer_*` the function works slower in case there is at least one unavailable instance. Closes tarantool#10596 and tarantool#10598
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Sep 26, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower than possible because only one active instance was needed to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. @TarantoolBot document Title: Experimental.connpool: new `filter()`, `call()` mode names The `connpool.filter()` options got new modes: - `alive` can be used to filter out only active connections matching other requirements. - The default mode is now named `any` (used by default when the mode is nil). It can be used to ignore instance status completely. - Other modes remained the same. The `connpool.call()` default filtering mode has now got a name `alive` (the mode is used if the mode is `nil`). It means "any alive instance". Other candidate filters for call execution remained the same. The `connpool.call()` function will now wait for any available instance matching the requirements in case of the `alive/ro/rw` modes. And it will try to connect to all of the matching instances if the mode is `prefer_ro`/`prefer_rw`. So if the modes are one of the `prefer_*` the function works slower in case there is at least one unavailable instance. Closes tarantool#10596 and tarantool#10598
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Sep 26, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower than possible because only one active instance was needed to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. @TarantoolBot document Title: Experimental.connpool: new `filter()`, `call()` mode names The `connpool.filter()` options got new modes: - `alive` can be used to filter out only active connections matching other requirements. - The default mode is now named `any` (used by default when the mode is nil). It can be used to ignore instance status completely. - Other modes remained the same. The `connpool.call()` default filtering mode has now got a name `alive` (the mode is used if the mode is `nil`). It means "any alive instance". Other candidate filters for call execution remained the same. The `connpool.call()` function will now wait for any available instance matching the requirements in case of the `alive/ro/rw` modes. And it will try to connect to all of the matching instances if the mode is `prefer_ro`/`prefer_rw`. So if the modes are one of the `prefer_*` the function works slower in case there is at least one unavailable instance. Closes tarantool#10596 and tarantool#10598
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Sep 26, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower than possible because only one active instance was needed to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. @TarantoolBot document Title: Experimental.connpool: new `filter()`, `call()` mode names The `connpool.filter()` options got new modes: - `alive` can be used to filter out only active connections matching other requirements. - The default mode is now named `any` (used by default when the mode is nil). It can be used to ignore instance status completely. - Other modes remained the same. The `connpool.call()` default filtering mode has now got a name `alive` (the mode is used if the mode is `nil`). It means "any alive instance". Other candidate filters for call execution remained the same. The `connpool.call()` function will now wait for any available instance matching the requirements in case of the `alive/ro/rw` modes. And it will try to connect to all of the matching instances if the mode is `prefer_ro`/`prefer_rw`. So if the modes are one of the `prefer_*` the function works slower in case there is at least one unavailable instance. Closes tarantool#10596 and tarantool#10598
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Sep 26, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower than possible because only one active instance was needed to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. @TarantoolBot document Title: Experimental.connpool: new `filter()`, `call()` mode names The `connpool.filter()` options got new modes: - `alive` can be used to filter out only active connections matching other requirements. - The default mode is now named `any` (used by default when the mode is nil). It can be used to ignore instance status completely. - Other modes remained the same. The `connpool.call()` default filtering mode has now got a name `alive` (the mode is used if the mode is `nil`). It means "any alive instance". Other candidate filters for call execution remained the same. The `connpool.call()` function will now wait for any available instance matching the requirements in case of the `alive/ro/rw` modes. And it will try to connect to all of the matching instances if the mode is `prefer_ro`/`prefer_rw`. So if the modes are one of the `prefer_*` the function works slower in case there is at least one unavailable instance. Closes tarantool#10596 and tarantool#10598
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Oct 24, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requiriments and synchroniouly select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. In case of using the priorities all of the candidates matching static properties are fetched. It may be optimized using the fact that technically it's possible to determine whether the reached replica has the maiximum priority and can be used without waiting other ones. Closes tarantool#10598 NO_DOC=performance improvement, no API change
georgiy-belyanin
added a commit
to georgiy-belyanin/tarantool
that referenced
this issue
Nov 28, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requirements and synchronously select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. Closes tarantool#10598 NO_DOC=no visible api changes
Totktonada
pushed a commit
that referenced
this issue
Nov 29, 2024
The connection pool `call()` function used to connect to all of the instances matching some specified static requirements and synchronously select one of the active. It was slower a lot times slower than its possible because the connpool only actually needs one active connection to perform the call. This patch makes the connection pool `call()` function work a bit smarter. Now if the priorities (`prefer_ro`/`prefer_rw` call modes) aren't used within the `connpool.call()` the pool will wait for any connection matching the requirements as a candidate to perform the call. Closes #10598 NO_DOC=no visible api changes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Currently
connpool.call()method connects to the instances through callingfilter()internally and then iterating through them. The filter meanwhile tries to access all of the instances matching the requirements.This call candidate selection can be done smarter if you connect to all of the instances in parallel and try to wait for the first one available matching the requirements.
It should match both static and dynamic (correct mode) requirements.
If one of the prioritized modes (
prefer_ro,prefer_rw) are chosen now it's suggested to fetch all of the instances matching static requirements and then selecting the most suitable one (though, it can be done smarter, if we can be sure that some of the fetched instances has the highest priority possible).Jira task: TNTP-399
The text was updated successfully, but these errors were encountered: