1

I have a small MySQL db running on AWS RDS t2.small instance.

So far, the CPU usage has been very predictable based on the traffic from my app.

Example:

1000 concurrent users = 15% CPU
2000 concurrent users = 30% CPU
3000 concurrent users = 45% CPU
4000 concurrent users = 60% CPU

My RDS is averaging just 15% with very predictable traffic spikes and I do have enough credits to cover the CPU spikes.

As my app is occasionally hitting 100% CPU, and since my "Reserved" instance will expire soon, I will have to soon decide on my next instance type.

As I'm not really able to benchmark the app/db and I will have to select another "Reserved" instance, considering all things being equal, the questions are:

Since the t2.small is only 1 vCPU | 2GB memory, if I upgrade to t3.medium with 2 vCPU and 4GB of memory, should I expect double capacity?

T2.small vs T3.medium

T2.small  | 1 vCPU | 2BG memory
T3.medium | 2 vCPU | 4GB memory

Should I expect the t3.medium will be running only at 30% with 4000 concurrent users?

Considering my app usage is growing around 10% per month, should the t3.medium keep me running for another year?

I don't really have a budget for anything fancier, so unless the AWS Aurora would be a better option, I would like to stay with the T3 instance family.

Here is a CPU screenshot.

enter image description here

SHOW GLOBAL STATUS LIKE '%connect%'

# Variable_name, Value
'Aborted_connects', '47'
'Connection_errors_accept', '0'
'Connection_errors_internal', '0'
'Connection_errors_max_connections', '0'
'Connection_errors_peer_address', '0'
'Connection_errors_select', '0'
'Connection_errors_tcpwrap', '0'
'Connections', '2986313'
'Max_used_connections', '113'
'Performance_schema_session_connect_attrs_lost', '0'
'Ssl_client_connects', '0'
'Ssl_connect_renegotiates', '0'
'Ssl_finished_connects', '0'
'Threads_connected', '4'
  • 1
    AWS Aurora is much more LIMITED in tuning allowed in Parameter groups. And innodb_io_capacity is limited to 200 and may not be modified for one of the 'limiting' Aurora factors. RDS has much more flexibility for tuning higher volume. Please post results of SHOW GLOBAL STATUS LIKE '%connect%'; – Wilson Hauck Apr 8 at 18:02
  • 1
    @WilsonHauck thanks for your feedback. As per your request, I have added the results for the: SHOW GLOBAL STATUS LIKE '%connect%' – WayBehind Apr 8 at 19:01
  • 1
    t3.medium for 10% growth per MONTH might be reasonable for the next year. Why do you expect 4000 concurrent users when at this point, after nearly 3 Million connections your max_used_connections was 113 (concurrent highest since instance start)? – Wilson Hauck Apr 8 at 20:13
  • 1
    @WilsonHauck sorry, perhaps I wasn't clear. These are not MySQL connections, but 4000 requests per minute through a load balancer. Pretty much, when I looked at the number of requests per minute, and compare them with my DB at the same time period, I can clearly see how is the traffic reflecting the CPU usage for my DB. So the question really was if having two CPUs and double memory will handle a double load. Is that the rule of thumb? Or is there some predicted performance loss when going from one to two CPUs and from two to four etc. – WayBehind Apr 8 at 21:11
  • 1
    Context switching loss should be negligible at 4,000 requests per minute. t3.medium should serve you well in AWS RDS. View my profile, Network profile for contact info. – Wilson Hauck Apr 8 at 21:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.