On Sat, 2005-08-13 at 10:14 +0200, Roman Rokytskyy wrote:

> > Throughput with embedded engine under Jaybird: 1,000,000 messages in 960
> > seconds. CPU was steady at 92% for the duration of the test.
> >
> > Improvement was 148 seconds, or 13%.
> >
> > I'll have to try with FB2 and Vulcan next, but that's a heavier duty set
> > of system changes. I think I'll get the wire protocol sorted out first.
>
> I would say that you have to check your code, for example check if you use
> connection and prepared statement pooling, etc. Improvement of only 13%
> means that in your system application is more busy doing different stuff,
> but not with data persistence. It might be that your application is really
> so busy, but run the profiler and check how much time application spends in
> org.firebirdsql.* classes and especially which method of GDS_Impl class is
> the most expensive - it should not be isc_dsql_prepare.
>
> Roman

If it's tied up in isc_dsql_prepare then my whole architecture is
broken. Prepare should only occur when a pool connection is constructed
(i.e. at startup), not during operation. Remember that odd pattern of
usage that exposed a bug in classic? That was the bit that guarantees I
should never hit a prepare during operation.

Profiling is a good idea, but also getting my test cases off of the
queue server would help to isolate things better.

I will have to check out ActiveQ, also. Thanks for the hints.