I'm looking to implement RDS Proxy but want to compare its performance against our current setup. We run a large Aurora database that we've realized may be over-specified at 8x.large, so I'm hoping to gather some data showing there's a performance enhancement with the proxy. What's the best way to simulate a high volume of connections for testing, and what should I track to measure improvement?
3 Answers
To test RDS Proxy effectively, start by collecting performance metrics and other relevant data from your current setup over a month's time. Once the RDS Proxy is implemented in production, monitor and gather data in a similar manner for another month. By comparing these two sets of results, you'll have a clearer picture of any improvements. Just a heads up, implementing it first in lower environments can help you identify potential issues before going live, but they might not provide full insight into performance gains in production. We've noticed that while RDS Proxy looked promising in staging, in production, it actually slowed us down due to how our app handled MySQL connections — every call ended up spinning up a new connection. If your RDS is set up with DNS aliases, switching between direct connections and the proxy should be a simple DNS change.
Why exactly do you need a proxy? Are you looking at it for connection pooling benefits? That could definitely streamline your database interactions and enhance performance if done right!
Yes, connection pooling is a key reason we're considering the proxy. It should help manage numerous connections more efficiently.
RDS Proxy is quite inexpensive relative to the total cluster size. Why not just set it up and apply it in either your live or staging environment and evaluate the results after a month? That might give you the insights you need without extensive pre-testing.
That's the plan! We'll use RDS Proxy before scaling down our cluster size, but we need this proof of concept to understand its impact before going live.
We plan to implement it in staging, too, but I agree that we won’t get precisely accurate data there. We're considering testing in the region with the least traffic as our proving ground. We're looking for exactly what you encountered about the 50ms slowdown in production since it’s vital to understand these impacts before going live.