If I understand you correctly, you don't actually need separate
connections for each device, you just chose to do it that way because
of how you understood superserver to work.

Creating a database connection is a fair bit of work in itself. In
fact as an experiment, create your 250 threads each with the database
connection, and dont run any inserts on it. It will still probably
fall over.

You should be able to use a global connection in all of your threads
without queuing though. Obviously with the nature of your work, you
will want to do some pretty serious load testing on it, but I do not
see a separate connection being of any benefit in this case.

Adam

>
> I'd chosen the connection per thread because the blurb about super
> server had been about its multithreading client connection capability,
> and it looked like a shortcut to avoid writing a message queuing
> mechanism (actually rereading that intro on the firebird download
> page, it looks like the xinetd connection setting would only apply to
> the classic server?).
> It was worth a try, but as ever you can't be lazy with design.
> However, thanks for the disabling indices thing - that could be very
> beneficial, I'll try some experiments.
>
> My application is a server that collects vital signs data from up to
> 250 medical devices. Each device could be supplying 20 or so variables
> every 5s, so the data throughput could be quite large (actually users
> are more likely to configure it to 20 variables every 15 minutes, but
> I still need to offer the capability).
> The actual processes connecting to the devices are quite light, and so
> far I'm looking at 3GHz P4 rack servers with ~1GB memory.
>
> Nik