0

I launched a AWS RDS MySQL instance, which is currently only accessed by 2 identical instances of a Play!-Framework application. This application has some akka scripts running, which access the DB (f.e. checking for old/unreferenced entries). Further, the DB currently still holds a table with BLOB data fields, which will be partially be filled with end-user data. I therefore try to benchmark what instance size the application requires, especially estimating user actions involving small queries (logging in) but also large queries (uploading/downloading BLOBs).

However, after setting up the instance, the connection count metric provided by AWS shows strange behaviour:

DB Connections on AWS RDS instance

Obviously an akka-script is running every ~15 minutes, pumping up the db connections up to 27. Most of the times the connections drop to 4 again for a couple of minutes, just to rise up again to 27. This leaves me puzzling about some questions:

  1. coming from .NET, I always engaged with DBs with USING, meaning that I connect to the DB, do my stuff there, disconnect and dispose the connection. So my DB connection would exist just for a couple of (milli)seconds, for the time of the query. Is this different in java/play? Or was it simply implemented poorly within the Play!App (which was not written by me)?
  2. why are my DB connections never 0? I understand that my 2 instances of the application might be hooked up permanently to the DB, but shouldn't this connection be pooled then? Right now it feels like every single query from the Play!App creates at least 2 new db connections.
  3. When I connect to the server via MySQL workbench, the connections jump from 27 to 29 (instead of 28). So maybe the db connections are simply not exactly accurate but maybe calculated through another metric (like freeable memory)?
  4. Should I be worried about this when scaling the RDS instance? If every user interaction uses a couple of db connections, I will hit a limit there quite soon (I did read about changing this value manually instead of having it calculated by AWS).
  5. Is there any way to see the current db connections in AWS/MySQL? Maybe this could help me finding out more about this issue...?
konrad_pe
  • 1,189
  • 11
  • 26

1 Answers1

1

There is a simple answer to most of your questions: Playframework uses a connection pool, which means that Play opens a number of connections and reuses them each time it needs to use a database connection. The number of connection into the pool can grow depending on how your application was configured and that is why you are seeing spikes in your monitoring.

See this question to understand why connection pools are important:

Why we need a connection pooling for JDBC?

Community
  • 1
  • 1
marcospereira
  • 12,045
  • 3
  • 46
  • 52
  • Thank you - I already found out that this pattern comes from BoneCP, which is used by my Playframework Version (2.3.8). Trying to switch to an alternative CP (Hikari) turned out to be quite a pain in the first approach, so I will go with BoneCP for now. Probably I never watched that closely to the DB connections of my asp.NET apps, but I never realized a similar pattern before. So to conclude, this is nothing to worry about? – konrad_pe Jan 06 '16 at 11:11
  • @konrad_pe have you tried [HikariCP Plugin for Playframework](https://github.com/edulify/play-hikaricp.edulify.com)? It should be straightforward to use. Also, you should probably worry about how many connections your database server can handle and consider it when configuring the pools for each application accessing that same database server. [HikariCP docs](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing) have a very good explanation about how to size your pool. – marcospereira Jan 06 '16 at 15:30
  • yes I did try that, however our playframework version is 2.3.8, the existing plugin causes some trouble with Java8. So while the implementation should take 5 lines of code and worked in my local IDE, it didn't run when deployed. My question was more concerning the current pattern caused by BoneCP; I don't want to upscale my AWS RDS instance and pay too much, just because the CP works inefficiently when in production. If this is just a matter of some performance %s, then it might be not worth the hassle? – konrad_pe Jan 07 '16 at 08:48
  • 1
    you are seeing an error with [HikariCP Plugin for Playframework](https://github.com/edulify/play-hikaricp.edulify.com) because it targets Java 8+ only. About BoneCP, as you was able to see, the pool is elastic and goes up and down as more connections are needed. You won't have a performance problem because of that if the pool is properly sized for your application/workload. – marcospereira Jan 12 '16 at 13:48