Re: Connection pooling w/ DBD::Gofer

In data 30 dicembre 2010 alle ore 18:33:19, Tim Bunce  
<[email protected]> 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