...

> But it takes aprox 24 seconds to terminate the last thread.

> As all threads are running in paralel, shouldn't all threads
> finish in aprox. 14 seconds also?

There are so many variables in what you are testing that it is
hard to know where to start.

The first thing you must understand is that unless you did this
using a 16-CPU system at each end (client and server) then the
threads are _not_ running in parrallel. They are being given
time-slices on whatever CPU resource is available. If you have
more threads than CPUs you are probably slowing things down
because of the overheads of swapping a thread in and out.


The CPU does not say "Here are 15 threads that I can tell are
absolutely identical, lets make certain that they each get the
same number of clock cycles." Instead it is rather more like
the service at a fast food restaurant: "Next!" ... whether you
get your burger in 2 minutes or 20 depends on many factors.

You could try to discover the cpu-time of each of your threads;
find out how much time your burger spent cooking versus how
long it spent waiting for while the boss's favourite customer
got his 20 burgers cooked (interrupts, drivers, services etc).

I can see those numbers for threads in Process Explorer so it
must be available from the Windows API somewhere. I suspect
even those times are unlikely to be completely consistent, but
I think they may be closer than simple start/finish times.
[And if you read up about how Windows schedules threads then
you may get some explanation for any time variations that you
are seeing.]


Alternatively (or as well) you could try to distinguish between
the time taken at the client from the time taken at the server.
You really need to take some more measurements (just before and
after all the various places you will be waiting for the
server) in order to distinguish time/delay at the client from
time/delay at the server. (And such would at least tell you
whether you should be posting your question here or to
firebird-support. :-)


Your test also needs to create a more statistically significant
sample. Execute your test some thousands of times. eg:

As soon as one thread finishes start another, keeping
it so that 16 threads are running all the time until
the test has completed x thousands of times
or
Run 16 threads and repeat the test inside each thread
(whether you measure time for each test or count how
many tests each thread has completed is up to you)

You may need to plot the results in various ways to see if
there is anything truly interesting in amongst it all. You
probably need to run the program several times to ensure that
you are getting a consistent/repeatable distribution of
results and not something quite random.

You can then start looking for issues. Are the last threads
always the slowest or the first few always the fastest? Or are
the faster/slower tests well distributed through total run?
Repeat the procedure for varying numbers of concurrent threads
to get an idea of how the situation varies under load.


There are lots of other things you would have to try before
you could pin the problem (if there is a problem) to any
particular code. But first make sure there is a problem by
ensuring that you are measuring what you think you are
measuring - at the moment there are way too many variables
for your measurements to be meaningful.

--
Geoff Worboys
Telesis Computing