--- In firebird-support@yahoogroups.com, "Adam" <s3057043@y...> wrote:

> --- In firebird-support@yahoogroups.com, "Nicholas Cain"
> <mymailinglists@n...> wrote:
> > --- In firebird-support@yahoogroups.com, "Ann W. Harrison"
> > <aharrison@i...> wrote:
> > > Nik wrote:
> > > > I have an application that creates 50 threads, and then every
> > > > 5 seconds all the threads attach and insert some data into a
> > firebird
> > > > Super Server 1.5 database (this is currently using the
> firebird
> > C++
> > > > api rather than things like ibpp etc).
> > > Ouch. In Firebird 1.5, connections are heavier-weight than they
> > could
> > > be. Could you leave the connections in place and just start &
> stop
> > > transactions? Transactions are much lighter weight. Each
> > connection
> > > has a separate copy of that part of the metadata that it uses.
> If
> > you
> > > kept the connection you'd not only keep the metadata, you might
> > also be
> > > able to keep the prepared insert statement...
> > > >
> > > >
> > > > Occasionally a thread will throw up;
> > > >
> > > > Unable to complete network request to host "127.0.0.1".
> > > > -Failed to establish a connection.
> > > > -Connection refused
> > >
> > > One possibility is that your Linux is configured (as many are by
> > > default) to limit the number of simultaneous connections.
> > >
> > > Regards,
> > >
> > > Ann
> >
> > I've found the linux connection limit in xinetd (thanks to Adam),
> > although I'm not sure it has made much difference yet. However,
> > preventing the repeated connections and leaving just transactions
> > sounds a good idea. I'll have a go and see where it gets me...
> >
> > thanks,
> > nik
>
> Sorry I was in a bit of a rush last night Nik, so I didn't get to
> answer properly. I agree totally with Ann's advice, 250 connections
> consume a lot of system resources, only use that model if you have no
> other choice. Unless you need Isolation between the inserts or you
> want to make sure any failed insert doesn't prevent other inserts
> from running, you can probably get away with just one transaction.
> What sort of hardware have you thrown at this project? If you are
> doing a lot of inserts, it will be faster to disable any indices
> before the inserts and re-enable them afterwards.
>
> 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