FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

Too late, this was already done.

The question here wasn't whether the pool server is perfect...merely whether
or not it should be included in the normal build process.

In my experience, stuff that is built and exercised regularly tends to get
more attention.  Bugs and problems get noticed and fixed more quickly.
Conversely, stuff that is distributed but not built tends to turn into
cruft.  I don't think the pool server would even build in the 0.60 release
because it was ignored (no one doing active development on FreeTDS was
paying any attention to it).

Since then, I've at least got it to build cleanly, and provided basic
configuration examples.  If you want to carry on from there, please do so!

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Friday, October 11, 2002 11:31 AM
To: TDS Development Group
Subject: [freetds] RE: pool server build


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:

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.

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.

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).

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!).


regards,

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


---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.