Application Slowness after migrating to ProxySQL

Mahendra Singh Bisht

unread,

Nov 6, 2025, 12:42:20 PMNov 6

to proxysql

Hi team,

I am fairly new in using ProxySQL and here is our current setup:

There are two ProxySQL nodes and both of their records are there in the DNS Server with the name : va-proxysql.
We have the ProxySQL VIP behind HAProxy for load balancing. The DNS name : va-proxysql points to the HAProxy VIP.

We updated our App to use DNS instead of HAProxy(Existing configuration for our App load balancing), but we noticed slowness in the App. The developer said that it took ~500ms to open connection vs usually it takes ~1ms.

Also, the query took longer than usual, we executed the queries via ProxySQL and it took 144, 263 and 39 seconds vs if we execute the queries directly then it took 0.422 , 0.203 and 0.406 sec.

So something is off on the ProxySQL between App and DB. We have the networking person checking on their end but I need to know how do we mitigate this? What areas should we be checking on the ProxySQL's end like any configurations/tunings or settings ?

DB Version : MySQL 5.7.40

ProxySQL Version : 2.4.7-5-gd467cc0, codename Truls

OS Version : CentOS Linux release 7.9.2009 (Core).

Regards,

MS

Dave Rix

unread,

Nov 7, 2025, 8:20:11 AMNov 7

to proxysql

Hey,

I'm not on the ProxySQL team, but I wanted to jump in and help you out.

I run a three-node ProxySQL cluster behind an AWS NLB, which handles upwards of 3000 parallel connections to an Aurora backend —we haven't noticed the kind of slowdown you are experiencing.

Have you tried making connections and running test queries directly to the DB from the ProxySQL host (not through ProxySQL), and then again using one of the application user credentials from the ProxySQL host to the DB via ProxySQL?
This would help to eliminate different parts of the communication pathways. I find it helpful to test for performance issues this way, starting as close to the DB as possible, then adding each additional hop as you step back through the network path to the application hosts.

This may help identify whether the issue is networking between ProxySQL and the DB, ProxySQL itself, or between the application and ProxySQL.

I've seen some strange routing paths where the comms path has gone halfway round the world before hitting the target, due to odd routing table configurations.

We intentionally introduced a slowdown when investigating an issue with a runaway application, but that involved adding entries to the 'mysql_query_rules' table for the particular user and setting the 'delay' field to delay query execution by a specified number of milliseconds.

On your ProxySQL nodes, use tools like 'htop' or just 'top' to watch the performance of the node from the operating system perspective, to make sure that the node itself isn't suffering performance issues - also, if you are saying the queries are taking a long time to complete - 263 seconds for instance - I presume that's not the actual query duration on the DB, but the complete start-to-finish time for the application to receive the requested data. You could try executing queries that do not return much data, perform the same operation as the slow queries - for example, wrap the slow query with an outer query that just counts the number of rows returned, meaning this entire operation is completed at the DB level, and just a single row is being returned - eg. "SELECT count(*) FROM ( your_query_here ) dd;"

Good luck with the investigations!

Regards,

Dave Rix

Senior Cloud Architect (AWS) / DevSecOps / MySQL DBA

Mahendra Singh Bisht

unread,

Nov 7, 2025, 8:40:49 AMNov 7

to proxysql

Hi Dave,

Thank you for your inputs, I tried making the connections and running sample test queries to the DB from the ProxySQL host. From the screenshot below, the yellow ones are proxysql nodes, the blue one is VIP and the neon/green one is the DB node. Connecting directly to MySQL takes ~1.4 s, whereas ProxySQL adds ~0.3–0.5 s to each connection setup. This indicates that there is an connection establishment delay. Can you direct as to what should we check here specifically?

I did checked the resource utilization on the proxysql nodes and the CPU utilization is < 5%, there is enough of Memory too.

We have got the following under mysql_query_rules:

mysql> select * from mysql_query_rules \G;
*************************** 1. row ***************************
rule_id: 1
active: 1
username: NULL
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: ^SELECT.*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: 1
replace_pattern: NULL
destination_hostgroup: 20
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: 1
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: 1
apply: 1
attributes:
comment: Route SELECT to reader
*************************** 2. row ***************************
rule_id: 2
active: 1
username: NULL
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: ^(UPDATE|INSERT|DELETE|REPLACE|SET|CREATE|DROP|ALTER).*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 10
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: 1
apply: 1
attributes:
comment: Route writes to writer
*************************** 3. row ***************************
rule_id: 3
active: 0
username: NULL
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: ^SELECT.*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 10
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: NULL
apply: 1
attributes:
comment: Backup route: SELECT to master
*************************** 4. row ***************************
rule_id: 4
active: 1
username: dataro13
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: ^SELECT.*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 30
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: NULL
apply: 1
attributes:
comment: NULL
*************************** 5. row ***************************
rule_id: 11
active: 0
username: datarw30
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: ^(UPDATE|INSERT|DELETE|REPLACE|SET|CREATE|DROP|ALTER).*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 11
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: NULL
apply: 1
attributes:
comment: NULL
*************************** 6. row ***************************
rule_id: 101
active: 0
username: NULL
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: ^SELECT.*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 10
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: NULL
apply: 1
attributes:
comment: Fallback SELECT to writer
*************************** 7. row ***************************
rule_id: 999
active: 0
username: NULL
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: .*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 10
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: NULL
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: NULL
apply: 1
attributes:
comment: Catch-all fallback
*************************** 8. row ***************************
rule_id: 9001
active: 1
username: statsro
schemaname: NULL
flagIN: 0
client_addr: NULL
proxy_addr: NULL
proxy_port: NULL
digest: NULL
match_digest: NULL
match_pattern: .*
negate_match_pattern: 0
re_modifiers: CASELESS
flagOUT: NULL
replace_pattern: NULL
destination_hostgroup: 20
cache_ttl: NULL
cache_empty_result: NULL
cache_timeout: NULL
reconnect: NULL
timeout: 300000
retries: NULL
delay: NULL
next_query_flagIN: NULL
mirror_flagOUT: NULL
mirror_hostgroup: NULL
error_msg: NULL
OK_msg: NULL
sticky_conn: NULL
multiplex: NULL
gtid_from_hostgroup: NULL
log: NULL
apply: 1
attributes:
comment: Reduce timeout to 5 min for statsro
8 rows in set (0.00 sec)

ERROR:
No query specified

The rule_id 1 is to route the select to the reader hostgroup followed by others, I don't see any abnormal settings here.

Regards,

MS

René Cannaò

unread,

Nov 7, 2025, 8:46:33 AMNov 7

to Mahendra Singh Bisht, proxysql

Hi Mahendra,

If "SELECT 1" against MySQL server takes 1.4 seconds ... I would be extremely worried, and clearly it has nothing to do with ProxySQL .

1.4 seconds to run "SELECT 1" ??

Also, I wonder ... since you are executing `mysql` with -p without specifying the password on the command line, are you really measuring the execution time of "SELECT 1" or how fast you can type the password?

--
You received this message because you are subscribed to the Google Groups "proxysql" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proxysql+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/proxysql/454f0d3a-5976-4a3e-8e67-b3b6660bfbf9n%40googlegroups.com.

Satria Dwi Putra

unread,

Nov 7, 2025, 9:11:15 AMNov 7

to René Cannaò, Mahendra Singh Bisht, proxysql

Basically you can check the log first in proxysql admin database monitor, check the result of table mysql_server_connect_log and mysql_server_ping_log. in this table you will be get information frequently connect and ping from proxysql to backend database node. ref : https://proxysql.com/documentation/backend-monitoring/

Regards,
Satria

To view this discussion visit https://groups.google.com/d/msgid/proxysql/CACJpxOZbB_bsh_zc%3DY1R9r7GeWrWnZoGy8N2R%2BnRjYqoh6BGUQ%40mail.gmail.com.

Mahendra Singh Bisht

unread,

Nov 7, 2025, 9:26:33 AMNov 7

to proxysql

Hey Rene,

Thank you for your response, I have updated the command line with the password and here is the output:

I still see the difference connecting to the DB directly vs ProxySQL. Any inputs?

More details:

root@va-mgmt-010:/home/devops# sudo hping3 -S -p 6033 10.64.97.126 -c 5
HPING 10.64.97.126 (bond0.165 10.64.97.126): S set, 40 headers + 0 data bytes
len=46 ip=10.64.97.126 ttl=62 DF id=0 sport=6033 flags=SA seq=0 win=29200 rtt=21.6 ms
len=46 ip=10.64.97.126 ttl=62 DF id=0 sport=6033 flags=SA seq=1 win=29200 rtt=18.9 ms
len=46 ip=10.64.97.126 ttl=62 DF id=0 sport=6033 flags=SA seq=2 win=29200 rtt=5.0 ms
len=46 ip=10.64.97.126 ttl=62 DF id=0 sport=6033 flags=SA seq=3 win=29200 rtt=19.2 ms
len=46 ip=10.64.97.126 ttl=62 DF id=0 sport=6033 flags=SA seq=4 win=29200 rtt=20.2 ms

--- 10.64.97.126 hping statistic ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 5.0/17.0/21.6 ms
root@va-mgmt-010:/home/devops# sudo hping3 -S -p 3306 10.64.96.190 -c 5
HPING 10.64.96.190 (bond0.165 10.64.96.190): S set, 40 headers + 0 data bytes
len=16436 ip=10.64.96.190 ttl=62 DF id=33700 sport=3306 flags=AP seq=0 win=15 rtt=0.0 ms
len=46 ip=10.64.96.190 ttl=62 DF id=0 sport=3306 flags=SA seq=0 win=29200 rtt=0.4 ms
len=16436 ip=10.64.96.190 ttl=62 DF id=33712 sport=3306 flags=AP seq=0 win=15 rtt=0.0 ms
len=16436 ip=10.64.96.190 ttl=62 DF id=33724 sport=3306 flags=AP seq=0 win=15 rtt=0.0 ms
len=16436 ip=10.64.96.190 ttl=62 DF id=33736 sport=3306 flags=AP seq=0 win=15 rtt=0.0 ms

--- 10.64.96.190 hping statistic ---
1 packets transmitted, 5 packets received, -400% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms

root@va-mgmt-010:/home/devops# mtr -rwc 5 10.64.97.126
Start: 2025-11-07T09:12:38-0500
HOST: va-mgmt-010 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.64.160.3 0.0% 5 131.5 74.0 0.7 131.5 54.6
2.|-- va-proxysql 0.0% 5 23.1 20.5 17.1 23.1 2.2
root@va-mgmt-010:/home/devops# mtr -rwc 5 10.64.96.190
Start: 2025-11-07T09:12:53-0500
HOST: va-mgmt-010 Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.64.160.2 0.0% 5 0.6 0.6 0.6 0.6 0.0
2.|-- va-db-replica-001 0.0% 5 0.1 0.1 0.1 0.1 0.0

I have asked the networking team to check, meanwhile can you let me know the variables that I should be checking in ProxySQL that would help in better connections management?

Regards,

MS

Mahendra Singh Bisht

unread,

Nov 7, 2025, 9:32:28 AMNov 7

to proxysql

Thank you for your response Satria, I checked these tables : mysql_server_connect_log and mysql_server_ping_log. I don't see any error(connect or ping), however I see that the connect_success_time_us is between 600-800ms while ping_success_time_us is between 100-300ms.

René Cannaò

unread,

Nov 7, 2025, 9:40:30 AMNov 7

to Mahendra Singh Bisht, proxysql

Hi Mahendra,

Wow, now we passed from seconds to milliseconds.

Indeed, previously you were measuring how fast you can type the password.

10.64.160.20 is proxysql , right? 7ms

10.64.96.190 is mysql, right? 9ms

Thus the claim "I still see the difference connecting to the DB directly vs ProxySQL." is incorrect.

There are cases in which connecting through proxysql is faster than connecting directly.

> round-trip min/avg/max = 5.0/17.0/21.6 ms

Network round trips vary so much that you can't make any conclusion with just few samples.

> 1 packets transmitted, 5 packets received, -400% packet loss

> ...

> I have asked the networking team to check ...

uhm?!? You have serious network issues. Absolutely no doubt.

> meanwhile can you let me know the variables that I should be checking in ProxySQL that would help in better connections management?

First fix the network.

My advice is stop thinking about ProxySQL until you fix the network.

To view this discussion visit https://groups.google.com/d/msgid/proxysql/258ea8c0-2dd3-4788-a634-c142b7cb1cdbn%40googlegroups.com.

Mahendra Singh Bisht

unread,

Nov 7, 2025, 9:50:56 AMNov 7

to proxysql

Thank you Rene for your comment.

Reply all

Reply to author

Forward