You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a lot of stress testing I've determined that
:pool => X,
:adapter => 'em_mysql2',
seems to be all you need for mysql connection pooling and it performs perfectly. I tested it by wrapping the relevant code in a bogus http server and blasting it with the likes of ab, httperf, and weighttp. You can clearly see
the connection pool at work in the mysql processlist.
I think this might be only the case if you use em-syncrony's ActiveRecord's client and ActiveRecord calls only, no cheating by grabbing a database connection from ActiveRecord and running raw queries.
This statement in the docs completely threw me off, and I'm not sure why its there - "If you need to control the connection pool size, use rack/fiber_pool."
I think this might be only the case if you use em-syncrony's ActiveRecord's client and ActiveRecord calls only, no cheating by grabbing a database connection from ActiveRecord and running raw queries.
Correct.
Anything else to resolve on this one? Have you resolved #159?
I haven't resolved 159 yet. If nobody else is having this problem, and there's nothing obvious to the experts that I'm doing something wrong, then I'll take another crack at it, it must be something unique to my situation.
In the activerecord spec
https://github.com/igrigorik/em-synchrony/blob/master/spec/activerecord_spec.rb
There is a pool of 10 specified.
But in the docs it says "If you need to control the connection pool size, use rack/fiber_pool."
Is this
actually doing anything?
I'm also getting the impression from the spec and docs that this pooling happens automagically but I have a feeling it isn't
Is this construct still the proper way to utilize a pool, outside of rails, even when using em-synchrony?
The text was updated successfully, but these errors were encountered: