> >We have a multithreaded application that serves both the internet and
> >local workstations. Firebird's current lack of SMP and Hyperthreading
> >support as well as CPU throttling problems are forcing management to
> >contemplate a major port to SQL Server 2000/2005.
>
> Why not use the Classic server? That will take five minutes (uninstall
> Superserver, install Classic) and invlove no changes whatsoever to
> databases or your applications.

I can't answer for Larry, but after reading the Vulcan documentation in
detail the other night, I can see why the classic model may still not be
enough for his application.

The single mutex architecture, aimed at multiple machines sharing a
common database file, imposes limits that are a pain in modern systems.
This was a large part of the reason that Jim started the Vulcan
project. Only one instance of the classic engine can actually do IO on
the database at any time (unless I misread the papers). So long as one
instance is doing I/O, all other instances are blocked.

A really nasty query that ties up resources for prolonged periods of
time has the potential to exhibit the symptoms he is describing on any
hardware. Per Jim's Vulcan documentation, it makes it impossible for
the current engine (classic or superserver) to gain any advantage
running on SMP or hyperthreaded machines.

If his application's concurrent workload is not too large, and he can
reuse connections between sessions (ie he is using connection pooling so
he doesn't encounter the metadata loading on every transaction), I agree
that classic may do the trick. At 5 minutes (less by my stopwatch),
it's a "least impact" test that costs nothing and has the potential to
solve some of his issues.

On the other hand, his big (*) queries suggest that some data modelling
might be in order. In my experience, queries that tie up a machine for
prolonged periods of time are generally suggestive (to me) of a data
model that needs refinement.