In data 30 dicembre 2010 alle ore 18:33:19, Tim Bunce
<tim.bu...@pobox.com> ha scritto:
Umm "useless, maybe idle, connections". That suggests that you're
connecting from general purpose web servers rather than using (e.g.) a
reverse proxy to route requests that require db access to a few specific
'heavy' web servers, leaving many 'light' servers to handle non-db
requests. [Just checking.]
These are app servers, so they use the db for nearly
every request unless it's a full cache hit.
I didn't express myself correctly, sorry.
What db? (Idle curiosity.)
MySQL/Percona 5.1. I hope to test Pg 9 Soon(tm).
- The majority of use cases are not transactional and
90% read/10% write, but I also have a few transactions,
and that is going to increase soon.
DBD::Gofer doesn't handle transactions.
Yes. From the docs I got that transactions could be supported
with a stream-oriented transport. IIUC, however, that also implies
that you lose a part of the connection pooling benefit, since your
connections are going to be busy with the db server.
In the worst case (all concurrent requests requiring a transaction)
you'd have 1 db connection slot per backend child, which brings us
to square 1, no connection pooling savings.
I'm clearly speculating here, but that 1:1 worst case could be
avoided by creating separate pools for transactions-free and
transactions-aware connections, using two different transports.
Or maybe having the begin_work() trigger a completely new,
stream-oriented connection, until a commit() or rollback()
is reached. I'm not saying this is a general purpose approach,
but could work for me.
I have an extensive test suite that I have run through Gofer
and the "null" transport, and I had expected failures.
I could experiment with the above ideas, if they seem
worthwile.
What's the maximum additional db request latency (in milliseconds)
you're willing to accept?
You're saying "additional", so I'm implying that this measures
the difference in time between:
- the system directly attached to MySQL
- the same system connecting through the local Gofer daemon
I guess ~10 ms per db request would be acceptable.
50 ms would probably be too much for this system.
I'm basically serving very fast API requests.
But let's talk :)
--
Cosimo
