FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Fri, 11 Oct 2002, Magnus Ahl wrote:

> Nicholas Castellano wrote:
> 
> > I'd like to promote the pool server to a first-class member of the FreeTDS
> > source tree.  Currently, we distribute it, and generate a Makefile for it,
> > but it we don't build it or install it by default.  Is there any
> > reason for me not to correct that situation?
> 
> Perhaps this should be considered once or twice. I've recently tested the
> tdspool program for performance reasons, and found a few quirks with it:

It is an experimental program.  Adding it to the automatic build is
orthogonal to how well it works or not.  I'd recommend displaying a big 
notice of it's experimental status at start up time, and build it anyway.  
jkl I assume you'll want a man page for this beast?
 
> 1. The program is full of "fprintf(stderr, ... )" and there is no way to
> turn of this _extremely_ verbose stderr logging, like a #define or something
> similar.

./tdspool [poolname] 2> /dev/null

Seriously, this is on the todo list.
 
> 2. The program behaves very strange on one of our servers (RedHat 8.0) in
> the way that it keeps all connections alive until the program is forcefully
> killed. Reverting from gcc 3.2 to gcc 2.95.3 and rebuilding the program and
> the library does not fix this problem.

That is strange behaviour, if you posted details, we might be able to do 
something with it.
 
> 3. The program segfaults spontaneously after some moderate load for 120
> seconds (apachebench with 1000 connections, 10 in parallel) and allocates
> more than the number of concurrent threads used in the load test (10 threads
> allocates 30 slots in tdspool).

120 seconds is the default idle timeout, I would guess it has something to 
do with that.
 
> 4. Does the program really work? I actually get less or the same number of
> accesses per second on our test webserver with pooling (apachebenc says 5.4
> req/sec with pooling vs. 7.4 req/sec without pooling). Also _both_ the
> database _and_ the webserver is _less_ loaded during the performance test
> with pooling enabled, and all programs (CGI-programs, pool-program and
> database) seem to be extremely idle as the load average never even reaches
> above 0.6. Similar tests with MySQL as a local database peaks the server at
> a load average of 10 and delivers 25 CGI-requests per second (Yes! that's
> five times faster, with a local database!).

Well, one would expect a local database to be much faster, but it's so 
apples and oranges as not to be a useful number.  A better number to look 
at if pooling is useful, is the average round trip time of the requests.  
If the members of the pool are bumping into the pool connection limit, 
than xact/second will be slower.

Anyway, all that said, it worked quite well for the configuration I tested 
it in.  But a sample size of 1 is nearly useless, and again I wouldn't be 
surprised that there are issues with it. 

> 
> regards,
> 
>  Infogate AB             Magnus.Ahl AT infogate.se
>  Storgatan 29                   tel: 035-171970
>  Box 345                      mobil: 702-118265
>  301 08 Halmstad                www.infogate.se
> 
>