MXS-122 makes persistent connections to backend database and only uses those connections. There can be upper and lower limit for these connections.

Who has reviewed the feasibility of this?

Hi, thanks for the answers !

The goal is not to refuse applications connections with an error, when the mysql/mariadb connections are fully used.
It is to put them in a backlog, until there is a free slot.

Example similar in other popular lb software:
Global maxcon = 4096
Per backend maxcon = 200

Hope this helps,
Joffrey

Thanks for the comment, Joffrey. I can see the attraction in principle, but have concerns over the practical implications in the software. Until the relevant router has been invoked (and there is an increasing number of different routers with different behaviours, plus we have the option of hierarchical routing where one router forwards to another router) MaxScale does not know which backend database server will be involved. It is therefore difficult (at the least) to know how to handle connection buffering prior to routing. Once routing has been involved, there is a quite complex set of data structures in play, and buffering these for later processing does not look straightforward. I am surprised that a feature of this complexity that has been nominated as minor priority would be allocated to a release prior to any evaluation (that I know of) of the volume of work required. The basis for the issue is that MaxScale is a lot more general than typical lb software.

Thanks Martin for the analysis.

Maybe it would be great to start with simple things, like limiting connections or implementing this throttling on the listener side ?

Something like:

[RW Split Listener]
type=listener
service=RW Split Router
protocol=MySQLClient
port=3306
max_connections=1000
max_extra/throttled_connections=200

Those new parameters would affect connections on the MaxScale backend directly (and indirectly on the MySQL/MariaDB Backends).
When 1000 connections app <--> maxscale are opened, new connections are still accepted (up to 200) but not sent to the router, until a slot frees up in the pool of 1000.

Currently, as far as I experience from the field, most of the maxscale users don't use complex routing/filtering, but simple round-robin or rw split.

What do you think ?

Joffrey

Removing fix version of 1.4.

Removed it from 1.5.0 for now.

Development has progressed, and there is now logic to handle the imposition of a limit on the number of connections to be accepted by MaxScale on a particular service. The logic is also in place to put a specified number of connections into a queue, after the limit has been reached. The logic does not exist to insert the queued connection requests back into active use. Given timescales, the current aim is to tidy up the limitation on number of connections, but to exclude queuing of connection requests for future development.

The limiting functionality is now operational, based on e.g. "max_connections=25" in the configuration of a service. After the specified number of connections have been made, a request for a connection will receive the standard error reply, 1040 Too many connections.

NOTE: without the mysql library, there is no practical way to translate the error message into a local language, it is hard coded as English.

Incorrect comparison fixed to stop limit being one higher than specified. The max_connections limit on a service is the functionality to be released in version 2.0. There is currently code under test that queues up requests beyond the connection limit and times them out after the specified limit (subject to the granularity of the housekeeper). Functionality for processing the queue as connections become available requires further work, although the principles are established.