-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use lazy connect and let server disconnect on inactivity #30
Comments
Sounds good to me :) Setting the connect strategy to lazy allows workers to (re-) start more quickly and reliably, and works around poolboy's annoying deficiency to crash an entire pool if one worker fails to (re-) start, too. One ugliness that remains is that part of it (the idle timeout) depends on the server, ie there is no way for the client to decide that it wants to be extra nice and close the connection when it has not been used for a while (maybe even to just close and revert to the not-connected state of lazy mode). |
Yes, I didn't even think about this. It's an extra benefit.
Hm... Then we lose the connection state, but as a non-default option with an explicit warning, perhaps yes. Anyway, with just the server disconnecting after 8 hours idle, the application will come to some balance of how many connections it needs within 24 hours. |
Oh, plus it has the benefit that workers will always start quickly. With poolboy, worker starts happen synchronously, blocking all other pool operations, so quick worker starts are good :)
Just a thought, I think not really worth it.
I guess so :) In any case, I think that this would be a good improvement, so I'm in favor of it :) |
Currently, when you start an application using MySQL/OTP+Poolboy, you immediately see a number of connections to the DB server. Most of them are idle.
This is an idea of reducing the number of connections to the server to what is actually needed. With MySQL/OTP 1.6.0, no error is logged when the server disconnects. This, with the new lazy connect strategy, allows us to have a more server-friendly approach:
{strategy, fifo}
option)The scenario would look like this:
I suggest we make these options the default in this project.
The text was updated successfully, but these errors were encountered: