On Feb 14, 2007, at 3:10 PM, Tim Bunce wrote:
The http transport will enable not just true connection pooling via
apache's acting as 'middleware', but also load balancing and response
caching via hardware web accelerators. (Or Squid or whatever caching /
reverse proxy / load balancing technology you want to use.)
I think Gearman can provide some of the same or similar benefits with
potentially lower overhead.
To try it,
[...]
Better than that... just set the DBI_AUTOPROXY env var to
dbi:Gofer:transport=gearman;url=127.0.0.1
and do "make test", then the *whole DBI test suite* will be run
through it!
When I only run one worker / transport end-point (what's the lingo
for this?) it seems to get stuck on executing a (random?) "ping"
request.
If I run two workers/end-points then all tests but the 85gofer.t test
succeed with DBI_AUTOPROXY.
To my surprise it's almost as fast to run the test suite "directly"
and "through gearman" - 24 vs 27 wall clock seconds on my system.
Index: lib/DBD/Gofer/Transport/gearman.pm
Ask, go ahead and check it in to the repository. With a few changes...
Ok - I'll do that over the weekend when I've had a chance to clean it
up a bit.
[....]
+package DBI::Gofer::Transport::gearman;
[...]
You could optimize that slighly by reusing the same $executor object.
Yup, that saved two wall clock seconds ("make test" with autoproxy
went from ~29-30 to 27 seconds).
I started out writing it to support different executor configs (like
the mod_perl target), but I realized that with gearman you probably
would just run different workers anyway and have them register
different "methods" for the different database targets.
[....]
- ask
--
http://develooper.com/ - http://askask.com/
