AWS RDS Proxy – сервис от AWS, позволяющий разгрузить сервера баз данных AWS RDS, в первую очередь за счёт переиспользования существующих подключений вместо открытия новых для выполнения запросов от клиентов.
Кроме того, RDS Proxy улучшает failover при переключении упавшего инстанса на резервный, например – когда AWS RDS Aurora выполняет переключение read-replica на роль master, если master ушёл в ребут.
Содержание
Как работает RDS Proxy?
См. RDS Proxy concepts and terminology
В целом, из всего, что нагуглил за время знакомства с сервисом – это аналог Proxy SQL для MySQL и pgproxy
для PostgreSQL.
Итак, у нас есть сервер баз данных, в этом примере говорим только о MySQL. На каждое новое подключение для выполнения запроса сначала устанавливается TCP-соединение между хостами клиента и сервера баз данных, затем выполняется handshake, и только потом начинается передача и непосредственно выполнение SQL-запроса. См. Connection Phase.
Все эти фазы отнимают и время CPU, и RAM для поддержания соединений. Кроме того, Proxy избавляет из необходимости продумывать логику в самом приложении для пересоздания подключения в случае проблем с ним.
Для демонстрации того, насколько реально это влияет на ресурсы сервера – давайте запустим mysqlslap
, который будет открывать 30 одновременных подключений, выполнять самый простой запрос типа select version()
, отключаться, и повторять всё заново, и так 1000 раз:
[simterm]
$ mysqlslap -h proxy-test-rds-aurora.dev.bttrm.local -u rds-proxy-user -pxie0AhN5bee9 --detach=1 --concurrency=30 --iterations=1000 --query 'select version();'
[/simterm]
И графики CPU и памяти:
RDS Proxy и “Too many connections“
Самое интересное случается, когда количество подключений к RDS Proxy превышает его “capacity” (позже увидим, где оно настраивается): в отличии от подключения к RDS напрямую, который в таком случае начнёт отбрасывать новые подключения с ошибкой “Too many connections” – RDS Proxy начнёт ставить подключения и запросы в очередь. Это приведёт к дОльшему выполнению запросов, но избавит именно от ошибок подключения, что очень приятно для приложения, и для клиентов, которые этим приложением пользуются.
Инстансы RDS Proxy располагаются в нескольких Avalability Zones, что обеспечивает их отказоутойчивость, и используют свои CPU и RAM, не затрагивая таким образом ресурсы самого сервера баз данных.
Connection pooling и multiplexing
Вместо того, что бы подключать приложение напрямую к серверу баз данных – мы настраиваем RDS Proxy и его Target Group (бекенд), к которому RDS Proxy открывает пул подключений (connection pool) через свои собственные ендпоинты.
Клиенты подключаются к RDS Proxy, и их запросы отправляются через пул коннектов самого Proxy к серверу баз данных. При этом часть запросов могут выполняться через уже установленное соединение к бекенду вместо открытия нового – multiplexing.
Failover
Failover – одна из многих приятных вещей в AWS RDS Aurora, когда при выходе из строя или перезагрузке Aurora-кластер сам переключает ендпоинты, направляя таким образом новые подключения на новый инстанс, например – когда Мастер становится Слейвом.
В обычном случае мы зависим от DNS и его времени обновления, что в лучшем случае займёт 10-20 секунд, за время которых клиенты могут пытаться подключаться на инстанс сервера баз данных, который уже недоступен (и мы часто сталкиваемся со случаями, когда приложение пытается выполнить какой-то UPDATE
на инстансе, который уже стал слейвом).
RDS Proxy сам мониторит состояние серверов в своей таргет-группе, и при необходимости быстро переключает пул коннектов на новый инстанс сервера баз данных.
Надо будет протестировать – очень любопытная вещь.
См. Improving application availability with Amazon RDS Proxy, Failover и A First Look at Amazon RDS Proxy.
Где пригодится RDS Proxy?
См. Planning where to use RDS Proxy.
Да много где. К примеру, есть сервера баз данных Dev-окружения, где сравнительно “тонкие” клиенты, но где QA-команда любит запускать различные нагрузочные тесты. В таком случае перед нагрузочным нам приходится увеличивать типы серверов, иначе тестировщики сталкиваются с ошибками “Too many connections“.
Также, RDS Proxy пригодится для серверов, которые обслуживают множество короткоживущих запросов типа mysql_ping
или для AWS Lambda functions, которые обычно выполняются сравнительно часто и быстро.
Полезно при использовании языков, которые не умеют в пулы коннектов, такие как PHP и Ruby.
Многие фреймворки пытаются ускорить свою работу, открывая пачку коннектов к серверу баз данных, и поддерживая их, что бы при поступлении новых запросов не тратить время на открытие нового соединения – для них тоже пригодится Прокси.
Ограничения RDS Proxy
Всё звучит очень вкусно, даже слишком, поэтому кратко рассмотрим ограничения, с которыми можем столкнуться при использовании AWS RDS Proxy. Также, см. ссылки в конце поста – там пара любопытных историй о проблемах, которые могут возникнуть при использовании SQL Proxy.
См. Quotas and limitations for RDS Proxy.
- RDS Proxy на данный момент доступен не во всех регионах
- RDS Proxy доступен только для MySQL и PostgreSQL
- RDS Proxy недоступен для кластеров Aurora Serverless
- RDS Proxy должен быть в той же VPC, где и сервер(а) баз данных, и не может быть доступен из мира (хотя сервера могут быть publicity accessible)
Стоимость RDS Proxy
Тут всё очень прозрачно: оплачиваем за количество доступных vCPU ($0.015 в us-east-1) на сервере/ах баз данных, которые входят в Target Group нашего Proxy.
К примеру, у нас инстанс Авроры db.t3.medium с двумя vCPU. Следовательно за его Прокси мы будем платить:
[simterm]
$ echo 0.015*2*24*30 | bc 21.600
[/simterm]
Чем тестировать?
Для проверки того, когда сервер начнёт отбрасывать подключения с “Too many connections” и для того, что бы отслеживать время выполнения запросов – набросал скрипт на Golang.
Go трогал последний раз почти два года тому, когда разбирался с указателями в Go, гофер из меня так себе – но скрипт рабочий:
package main import ( "os" "time" "database/sql" "fmt" "strconv" _ "github.com/go-sql-driver/mysql" ) func main() { dbHost := os.Getenv("RDS_HOST") dbUser := os.Getenv("RDS_USER") dbPass := os.Getenv("RDS_PASS") dbName := os.Getenv("RDS_DB") // create a connection object db' db, err := sql.Open("mysql", dbUser+":"+dbPass+"@tcp("+dbHost+":3306)/"+dbName) if err != nil { panic(err) } // close after main() finished defer db.Close() // check if we can establish a real connection if err := db.Ping(); err != nil { panic(err) } dbInter, err := strconv.Atoi(os.Getenv("RDS_ITERATIONS")) for i := 1; i < dbInter; i++ { start := time.Now() var vname string var conns int fmt.Printf("\nIneration: %d", i) // get currently connected threads/clients, save its number to the conns' var err = db.QueryRow("show status where `variable_name` = 'Threads_connected'").Scan(&vname, &conns) // intercept the 'Too many connections' here if err != nil { fmt.Printf("\n%s\n", err) } else { // run a query and leave it for 20 seconds go func() { _, err := db.Query("SELECT sleep(100)") if err != nil { panic(err) } }() // this includes default RDS threads - 2 if no Proxy, 4 with Proxy fmt.Printf("\nConnected: %d", conns) } // make sleep between iterations so we can see graph in the CloudWatch metrics time.Sleep(500 * time.Millisecond) fmt.Printf("\nExecution time: %s\n", time.Since(start)) } fmt.Println("Fin") }
Создаёт подключение, потом в цикле выполняет запросы, в процессе выполнения выводит количество активных тредов в MySQL (читай – подключений), плюс время выполнения каждого, и текущую итерацию.
Дальше уже для нагрузочного тестирования – используем mysqlslap
, а ещё случайно увидел утилиту mysqltest
, но не пользовался.
Подготовка – сеть, EC2, RDS Aurora
Настройка сети
Для тестирования – создадим отдельную VPC, подсети, небольшой кластер AWS RDS Aurora и тестовый ЕС2, с которого будем подключаться.
Создаём VPC:
Создаём три подсети – одна публичная, в eu-west-2a, и две приватных – в eu-west-2b и eu-west-2c:
Создаём Internet Gateway для публичной подсети:
Подключаем к VPC:
Находим Route Table публичной посети, добавляем маршрут в 0.0.0.0/0 через созданный выше IGW:
Тестовый EC2
Запускаем тестовый EC2 в публичной подсети, подключаем ему публичный IP:
Проверяем подключение:
[simterm]
$ ssh -i rds-proxy-test-ec2-eu-west-2-rsa.pem [email protected] ... root@ip-10-0-0-97:/home/ubuntu#
[/simterm]
Устанавливаем mysql-tools
и Golang:
[simterm]
root@ip-10-0-0-97:/home/ubuntu# apt update && apt -y install mysql-client golang
[/simterm]
Тестовый RDS Aurora
Переходим в RDS > Subnet Groups, создаём новую группу, в которую включаем наши приватные подсети из Avvailability Zones eu-west-2b и eu-west-2c:
Создаём кластер Aurora:
Для генерации паролей я обычно использую консольную утилитку pwgen
:
[simterm]
$ pwgen 12 -1 Lohn1aiceiPh
[/simterm]
Указываем имя кластера, рутового пользователя и его пароль:
Используем наименьший доступный тип инстанса, добавим Multi-AZ:
Настраиваем сеть – выбираем VPC, нашу Subnet Group, публичный доступ не включаем, создаём новую Security Group rds-proxy-test-aurora-cluster-sg:
Запускаем создание кластера, пока он создаётся – находим созданную Security Group:
И добавляем в неё Security Group нашего инстанса EC2, что бы получить доступ для тестов:
Вкладку с Security Group для Aurora можно оставить открытой – она нам ещё пригодится во время настройки RDS Proxy.
Проверяем подключение с EC2:
[simterm]
root@ip-10-0-0-97:/home/ubuntu# mysqladmin -u admin -p -h rds-proxy-test-aurora-cluster.cluster-ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com status Enter password: Uptime: 175 Threads: 5 Questions: 1176 Slow queries: 0 Opens: 140 Flush tables: 1 Open tables: 121 Queries per second avg: 6.720
[/simterm]
Создаём тестовую базу, пользователя:
[simterm]
mysql> create database `rds-proxy-db`; Query OK, 1 row affected (0.01 sec) mysql> create user 'rds-proxy-user'@'%' identified by 'xie0AhN5bee9'; Query OK, 0 rows affected (0.01 sec) mysql> grant all privileges on `rds-proxy-db`.* to 'rds-proxy-user'@'%'; Query OK, 0 rows affected (0.00 sec)
[/simterm]
Проверяем доступ ещё раз:
[simterm]
root@ip-10-0-0-97:/home/ubuntu# mysql -u rds-proxy-user -p -h rds-proxy-test-aurora-cluster.cluster-ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com Enter password: ... mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | rds-proxy-db | +--------------------+
[/simterm]
Тестирование количества подключений #1: на RDS Aurora
Сначала проверим на каком количестве активных подключений мы начнём получать “Too many connections” от самого кластера Aurora, без RDS PRoxy.
Проверяем макс клиентов:
[simterm]
mysql> show variables like "max_connections"; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 45 | +-----------------+-------+
[/simterm]
Готовим скрипт (не умею я в новую систему модулей, делаю по-старинке):
[simterm]
ubuntu@ip-10-0-0-97:~$ export GO111MODULE=off ubuntu@ip-10-0-0-97:~$ go get github.com/go-sql-driver/mysql
[/simterm]
Задаём переменные:
[simterm]
$ export RDS_HOST=proxy-test-rds-aurora.dev.bttrm.local $ export RDS_USER=rds-proxy-user $ export RDS_PASS=xie0AhN5bee9 $ export RDS_DB=rds-proxy-db $ export RDS_ITERATIONS=100
[/simterm]
Домен proxy-test-rds-aurora.dev.bttrm.local направлен на мастер-инстанс Aurora. Для Proxy потом добавим домен proxy-test-rds-proxy.dev.bttrm.local. См. AWS: Route53 Private Hosted Zones – прячем домены от мира.
Запускаем скрипт:
[simterm]
ubuntu@ip-10-0-0-97:~$ go run mysql-connect-test.go Ineration: 1 Connected: 7 Execution time: 504.09813ms ... Ineration: 39 Connected: 45 Execution time: 513.671499ms Ineration: 40 Error 1040: Too many connections Execution time: 528.578825ms Ineration: 41 Error 1040: Too many connections ... Ineration: 99 Error 1040: Too many connections Execution time: 504.961624ms Fin
[/simterm]
Отлично – на 45+ коннектах мы начали отваливаться, как и ожидалось.
Создание RDS Proxy
Ну и наконец-то приступаем к RDS Proxy.
AWS Secret Manager
Сначала создаём секрет – переходим в Secrets Manager, кликаем Store a new secret, выбираем тип Credentials for Amazon RDS database.
Указываем логин и пароль, внизу выбираем кластер Авроры, к которому секрет применяется:
Задаём имя секрета, сохраняем:
RDS Proxy Security Group
С Security Group есть два варианта: использовать Security Group, которую делали для нашей Авроры – тогда в ней надо добавить правило MySQL и в source указать ID этой же группы, т.е. разрешить ей “ходить саму на себя”.
Другой вариант – сделать новую Security Group для инстанса RDS Proxy, а в Security Group кластера Авроры разрешить доступ с Security Group нашего Proxy.
Лучше, думаю, отдельную – мало ли, как в будущем будем менять правила в группе сервера баз данных, а мы тут стараемся всё-таки что около-продакшеновское построить, поэтому будем делать сразу правильно, где можно.
Копируем группу:
Сохраним как rds-proxy-test-proxy-sg:
Копируем ID новой группы:
Редактируем Security Group Авроры, добавляем в ней доcтуп из новой Security Group, которая для Proxy:
И только теперь переходим в RDS > Proxies, и начинаем создавать сам RDS Proxy.
Создание RDS Proxy
Кликаем Create proxy, задаём имя, тип MySQL, TLS пока не трогаем:
Настраиваем Target Group – выбираем кластер Aurora, в пуле коннектов укажем 100% – это будет 45 коннектов пула самого RDS Proxy, 100% от капасити инстанса RDS Aurora:
Отмечаем Include reader – RDS Proxy определит, что у нашей Aurora есть slave-инстанс со своим read-only ендпоинтом, и создаст такой же ендпоинт у себя. Тогда приложения, которые используют мастер для всех write/update операций будут по-прежнему ходить через один ендпоинт, а все запросы типа SELECT
будут как и раньше ходить на слейв-инстансы.
В Additional target group configuration можно настроить пиннинг – пока пропустим, см. Avoiding pinning.
Настраиваем Connectivity – выбираем секрет из Secrets Manager, оставляем Create IAM Role, IAM-аутентификацию тут не используем, выбираем теже приватные подсети, которые использовали в Subnet Group при создании Aurora-кластера.
В Additional connectivity configuration выбираем Security Group, которую создавали для RDS Proxy:
Ждём статус Available:
Статус таргет-группы можно проверить с AWS CLI:
[simterm]
$ aws --region eu-west-2 rds describe-db-proxy-targets --db-proxy-name rds-proxy-test-proxy { "Targets": [ { "Endpoint": "rds-proxy-test-aurora-cluster-instance-1-eu-west-2b.ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com", "TrackedClusterId": "rds-proxy-test-aurora-cluster", "RdsResourceId": "rds-proxy-test-aurora-cluster-instance-1-eu-west-2b", "Port": 3306, "Type": "RDS_INSTANCE", "Role": "UNKNOWN", "TargetHealth": { "State": "UNAVAILABLE", "Reason": "PENDING_PROXY_CAPACITY", "Description": "DBProxy Target is waiting for proxy to scale to desired capacity" } }, { "RdsResourceId": "rds-proxy-test-aurora-cluster", "Port": 3306, "Type": "TRACKED_CLUSTER" }, { "Endpoint": "rds-proxy-test-aurora-cluster-instance-1.ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com", "TrackedClusterId": "rds-proxy-test-aurora-cluster", "RdsResourceId": "rds-proxy-test-aurora-cluster-instance-1", "Port": 3306, "Type": "RDS_INSTANCE", "Role": "UNKNOWN", "TargetHealth": { "State": "UNAVAILABLE", "Reason": "PENDING_PROXY_CAPACITY", "Description": "DBProxy Target is waiting for proxy to scale to desired capacity" } } ] }
[/simterm]
Минут через 5 RDS Proxy пишет, что готов:
Но его ендпоинты и подключение к таргет-группам ещё настраиваются.
В целом процесс занял около 10-15 минут:
[simterm]
$ aws --region eu-west-2 rds describe-db-proxy-targets --db-proxy-name rds-proxy-test-proxy { "Targets": [ { "RdsResourceId": "rds-proxy-test-aurora-cluster", "Port": 3306, "Type": "TRACKED_CLUSTER" }, { "Endpoint": "rds-proxy-test-aurora-cluster-instance-1.ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com", "TrackedClusterId": "rds-proxy-test-aurora-cluster", "RdsResourceId": "rds-proxy-test-aurora-cluster-instance-1", "Port": 3306, "Type": "RDS_INSTANCE", "Role": "READ_WRITE", "TargetHealth": { "State": "AVAILABLE" } }, { "Endpoint": "rds-proxy-test-aurora-cluster-instance-1-eu-west-2b.ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com", "TrackedClusterId": "rds-proxy-test-aurora-cluster", "RdsResourceId": "rds-proxy-test-aurora-cluster-instance-1-eu-west-2b", "Port": 3306, "Type": "RDS_INSTANCE", "Role": "READ_ONLY", "TargetHealth": { "State": "AVAILABLE" } } ] }
[/simterm]
В AWS Route53 создаём запись proxy-test-rds-proxy.dev.bttrm.local с типом CNAME
на адрес мастер-ендпоинта Proxy – rds-proxy-test-proxy.proxy-ci9hdkrgdpwy.eu-west-2.rds.amazonaws.com.
С тестового ЕС2 проверяем мастер-ендпоинт RDS Proxy, используя логин-пароль от Aurora:
[simterm]
ubuntu@ip-10-0-0-97:~$ mysqladmin -h proxy-test-rds-proxy.dev.bttrm.local -u rds-proxy-user -p status Enter password: Uptime: 13645 Threads: 8 Questions: 1003139 Slow queries: 0 Opens: 118 Flush tables: 1 Open tables: 111 Queries per second avg: 73.516
[/simterm]
В случае проблем с подключением – можно заглянуть на страничку Troubleshooting for RDS Proxy.
Тестирование количества подключений #2: через RDS Proxy
Обновляем переменную для скрипта – указываем адрес RDS PRoxy:
[simterm]
ubuntu@ip-10-0-0-97:~$ export RDS_HOST=proxy-test-rds-proxy.dev.bttrm.local
[/simterm]
Запускаем повторный тест – в прошлый раз мы получили “Too many connections” на 40-ой итерации, а сейчас:
[simterm]
... Ineration: 38 Connected: 44 Execution time: 518.142051ms Ineration: 39 Connected: 44 Execution time: 1m19.997379109s Ineration: 40 Connected: 44 Execution time: 515.37535ms ... Ineration: 76 Connected: 44 Execution time: 508.229272ms Ineration: 77 Connected: 44 Execution time: 1m19.239202385s Ineration: 78 Connected: 44 Execution time: 516.224887ms ... Ineration: 99 Connected: 44 Execution time: 507.983456ms Fin
[/simterm]
И что мы видим?
- не пришло ни одного сообщения “Too many connections” – RDS Proxy ставил запросы в очередь на выполнение
- некоторые запросы выполнялись не ~500ms, как задано в
time.Sleep(500 * time.Millisecond)
между итерациями, а почти две минуты – RDS Proxy ждал, пока закончится один из предыдущих запросовSELECT sleep(100)
, 100 секунд, после чего запускал выполнение следующего
Т.е. новые запросы ожидали свободных коннекшенов в пуле Proxy, что бы начать выполнение.
Latency (время ответа) местами выросло – но это намного лучше, чем ловить на API-бекенде мобильного приложения 500-ые ошибки, правда?
Нагрузочное тестирование
Ну и самые интересные результаты получаются уже с использованием mysqlslap
.
Тут стоит учитывать, что тесты весьма синтетические-искусственные, и реальной картины для реального приложения не покажут – там надо проводить свои тесты, отслеживать ошибки, время ответа и так далее.
Первый прогон.
Используем:
- хост: напрямую на Аврору, proxy-test-rds-aurora.dev.bttrm.local
--detach=1
: выполняем новое подключение после каждого запроса--concurrency=45
: 45 одновременных подключений, наш лимит сервера изmax_connected_threads
--iterations=10
: каждый клиент выполняет 10 запросов--query 'select version();'
: и простой запрос на получение версии MySQL
Запускаем – и сразу ловим “Too many connections“:
[simterm]
ubuntu@ip-10-0-0-97:~$ mysqlslap -h proxy-test-rds-aurora.dev.bttrm.local -u rds-proxy-user -pxie0AhN5bee9 --detach=1 --concurrency=45 --iterations=10 --query 'select version();' mysqlslap: [Warning] Using a password on the command line interface can be insecure. mysqlslap: Error when connecting to server: 1040 Too many connections ...
[/simterm]
Уменьшаем клиентов до 30:
[simterm]
ubuntu@ip-10-0-0-97:~$ mysqlslap -h proxy-test-rds-aurora.dev.bttrm.local -u rds-proxy-user -pxie0AhN5bee9 --detach=1 --concurrency=30 --iterations=10 --query 'select version();' mysqlslap: [Warning] Using a password on the command line interface can be insecure. Benchmark Average number of seconds to run all queries: 0.762 seconds ...
[/simterm]
Время – 0.762 seconds.
А теперь – тоже самое, но через RDS Proxy – меняем --host
на proxy-test-rds-proxy.dev.bttrm.local, те же 30 клиентов:
[simterm]
ubuntu@ip-10-0-0-97:~$ mysqlslap -h proxy-test-rds-proxy.dev.bttrm.local -u rds-proxy-user -pxie0AhN5bee9 --detach=1 --concurrency=30 --iterations=10 --query 'select version();' mysqlslap: [Warning] Using a password on the command line interface can be insecure. Benchmark Average number of seconds to run all queries: 0.264 seconds
[/simterm]
Время – 0.264 seconds.
Попробуем увеличить клиентов до 45:
[simterm]
ubuntu@ip-10-0-0-97:~$ mysqlslap -h proxy-test-rds-proxy.dev.bttrm.local -u rds-proxy-user -pxie0AhN5bee9 --detach=1 --concurrency=100 --iterations=10 --query 'select version();' mysqlslap: [Warning] Using a password on the command line interface can be insecure. Benchmark Average number of seconds to run all queries: 0.723 seconds
[/simterm]
Время – 0.723 секунд.
И жахнем 200 клиентов:
[simterm]
ubuntu@ip-10-0-0-97:~$ mysqlslap -h proxy-test-rds-proxy.dev.bttrm.local -u rds-proxy-user -pxie0AhN5bee9 --detach=1 --concurrency=200 --iterations=10 --query 'select version();' mysqlslap: [Warning] Using a password on the command line interface can be insecure. Benchmark Average number of seconds to run all queries: 1.796 seconds
[/simterm]
Время – 1.796, но по-прежнему – “Ни единого разрыва“!
В целом – RDS Proxy выглядит крайне многообещающе, но перед самым Новым Годом, когда у нас ожидаются максимальные нагрузки, решили не вводить в работу – продолжим тестирование уже в 2022 году.
И обязательно посмотрите ссылки по теме – не всё может оказаться так гладко, как хотелось бы.
Ссылки по теме
- What is multiplexing?
- Scaling MySQL stack, ep. 4: Proxies – в целом про SQL Proxy
- Scaling MySQL stack, ep. 3: Observability – немного оффтоп, но понравилось – добавление комментариев к запросам для дебага. Вообще очень толковый блог от сотрудника Spotify.
- The ProxySQL multiplexing wild goose chase – проблемы при мультиплексировании
- MySQL Adventures: How max_prepared_stmt_count can bring down production – проблемы при мультиплексировании
- A First Look at Amazon RDS Proxy && A Second Look at Amazon RDS Proxy
- Types of Overhead and Where it Comes From
- MySQL Adventures: Reduce MySQL Memory Utilization With ProxySQL Multiplexing