Update release notes and documentation for the Throttle Filter

and Adaptive Routing

Documentation/Changelog.md

@@ -9,6 +9,7 @@
 * A Comment filter has been added.
 * Services and filters can be created at runtime via the REST API
 * Runtime router reconfiguration is now possible
+* New Throttle filter that replaces and extends on the limit_queries functionality
 * MaxCtrl
   * The `create monitor` command now accepts a list of key-value parameters
   * The new `drain server` drains the server of connections
@@ -20,6 +21,7 @@
   * Consistent reads on slaves via MASTER_GTID_WAIT
   * Transaction load balancing for normal transactions
   * Support for runtime router reconfiguration
+  * A new load balancing method: ADAPTIVE_ROUTING
 * Experimental resultset concatenation router, `cat`
 * The schema router is now capable of table family sharding.
 * The binlog router can now automatically switch to secondary masters

Documentation/Release-Notes/MaxScale-2.3.0-Release-Notes.md

@@ -219,6 +219,10 @@ The `source` parameter can now contain a list of comma separated addresses.
 The SchemaRouter is now capable of table family sharding. Please see the
 SchemaRouter [documentation](../Routers/SchemaRouter.md) for details.
 
+### Throttle filter
+The [throttlefilter](../Filters/Throttle.md) replaces and extends on the limit_queries
+functionality of [the Database Firewall filter](../Filters/Database-Firewall-Filter.md).
+
 ### Interactive Mode for MaxCtrl
 
 ### ReadWriteSplit
@@ -258,6 +262,10 @@ transactions (i.e. `START TRANSACTION` or `BEGIN`) are load balanced across
 slaves. If the transaction tries to modify a row, it is migrated to the master
 and rolled back on the slave.
 
+#### 'Adaptive Routing'
+A new load balancing method. Server load conditions are proxied by measuring
+query response times for each server.
+
 ### MaxCtrl
 
 #### Interactive Mode for MaxCtrl

Documentation/Routers/ReadWriteSplit.md

@@ -150,16 +150,26 @@ Where `<criteria>` is one of the following values.
 * `LEAST_ROUTER_CONNECTIONS`, the slave with least connections from this service
 * `LEAST_BEHIND_MASTER`, the slave with smallest replication lag
 * `LEAST_CURRENT_OPERATIONS` (default), the slave with least active operations
+* `ADAPTIVE_ROUTING`, based on server average response times. See below.
 
 The `LEAST_GLOBAL_CONNECTIONS` and `LEAST_ROUTER_CONNECTIONS` use the
 connections from MariaDB MaxScale to the server, not the amount of connections
 reported by the server itself.
 
-`LEAST_BEHIND_MASTER` does not take server weights into account when choosing a
-server.
+`LEAST_BEHIND_MASTER` and `ADAPTIVE_ROUTING` do not take server weights into account
+when choosing a server.
+
+`ADAPTIVE_ROUTING` Measures average server response times. The server averages
+are used as proxies of server load conditions. At selection time the averages
+are copied and modified to favor faster servers, while at the same time
+guaranteeing at lest some traffic to the slowest servers. The server selection
+is probabilistic based on roulette wheel selection.
 
 #### Server Weights and `slave_selection_criteria`
 
+NOTE: Server Weights have been deprecated in MaxScale 2.3 and will be removed
+at a later time.
+
 The following formula is used to calculate a score for a server when the
 `weightby` parameter is defined.
 

server/core/server.cc

@@ -1577,14 +1577,20 @@ void Server::response_time_add(double ave, int num_samples)
     int current_max = m_response_time.sample_max();
     int new_max {0};
 
+    // This server handles more samples than EMA max.
+    // Increasing max allows all servers to be fairly compared.
     if (num_samples >= current_max)
     {
         new_max = num_samples * drift;
     }
+    // This server is experiencing high load of some kind,
+    // lower max to give more weight to the samples.
     else if (m_response_time.average() / ave > 2)
     {
         new_max = current_max * 0.5;
     }
+    // Let the max slowly trickle down to keep
+    // the sample max close to reality.
     else
     {
         new_max = current_max / drift;