I agree
I've noticed you are using connection pooling. Through some reading and internal testing I came through the following conclusions:
1) Pools size sweet spot seems to be somewhere between 5-10. I used to have larger pool sizes until I read up on HikariCP (
https://github.com/brettwooldridge/HikariCP) and used some internal testing to come to the same conclusion that larger pool sizes do not provide larger benefits. A super slow network and/or some super slow (really slow) queries may necessitate larger pool sizes, but those cases seem to be on the extreme end of pool size usage.
2) When the client and the server are on the same machine or located on the same fast (1Gbits+) network, pooling does not seem to give you any gains, especially if the queries are pretty quick (the ones listed above should be quick). In these cases, pooling just adds another layer of complexity and may add more pressure on memory (an item which you seem to care a lot about). In your code above
would just return a standard SQL object and in the WebSocket
would just need to be commented out (you don't close the SQL object until the server object quits). It seems counter-intuitive, but my own internal testing has shown that pooling provided no benefit in these cases. At that point, SQL pooling does check if the connection is good for you, but you could handle that yourself (most pools just do a "SELECT 1" query against the server as a means to check if it is up and running).
Note: This is not a opinion of a DB expert, just some observations gained through reading and doing some inhouse testing.