?

> > > But classic I think is supposed to cater for greater concurrent
> > users that
> > superserver.

Threads are more light weight than processes, so you should be able to handle
more concurrent users on SuperServer with less resources.
There is a limit in SuperServer of 1024 concurrent connections, there is
no limit in Classic, but you will need some serious hardware to get to
1024 users of CLassic. The most I have seen on CLassic in a real environment
is approx 200. Although somebody can correct me if they know of more.

> > No. Not AFAIK.
> > classic is *required* to use SMP systems.

Currently, Vulcan will correct this problem.

> > Each client gets its own server process and those can be bound to one
> > processor.

How does this work? True Classic has its own server process, per process
but when was it bound to a specific processor? A Classic process could be
picked up by any processor at any time assuming it had exhausted it specifc
processors quantum.

> > However, more threads require more memory and so the client
> > connection count

Hmm don't think so.

> > is much more limited than the connection count with superserver,
> > which uses
> > one process only and at least one thread per client and therefor can share
> > memory...

SuperServer is a multi-threaded process (if not finely grained), it shares
the Lock Manager, Metadata and Data Caches. Classic doesn't share Metadata and
Data Caches, each process carries its own. The Lock Manager is shared, but only
in the sense that each process needs to synchronise with it, every time
the process wants to actively do something in the database.

> So I suppose we are saying that Classic is best advised for fewer
> concurrrent users but greater loads per user than superserver which can
> handle greater concurrent numbers on lighter simultaneous loads??

Classic is an artifact, the future is a lightly grained multi-threaded
server across all platforms, that can share threads across multiple CPU's.
However Classic has value in that if a process dies, it doesn't take down
the main server process, as would happen on SuperServer, so Classic has its
place where robustness is specifically required. But Classic is greedier
on resources, and will max out when contention for the Database Header Page
in teh Lock Manager becomes too much for the number of users. The fact that
Classic supports SMP currently is due to its architectural heritage and the
fact that the implementation of threads in SupperServer wasn't done with SMP
in mind.

Regards
Paul