| Subject | Re: [IB-Architect] Classic vs. superserver (long, very very long) |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2002-10-08T20:55:56Z |
At 09:43 PM 10/8/2002 +0200, Pavel Cisar wrote:
to do with the build procedures. Classic retained build
procedures from a time when InterBase ran on dozens of
platforms. Superserver started as a windows-only thing
and the builds we inherited ... I guess I don't have to
say more.
Classic is inherently less portable because it uses inter-
process communication and shared memory Until quite recently,
Unix/Posix had enough different ways of handling those that
most implementations were both compliant and incompatible.
more consistent than the combination of signals and
shared memory, so the problems are more from the build
(I think) than from the architecture.
of the user base more interesting. A shared server starts to
be a good thing at two users - the shared caches reduce the load
on the disk, which is our greatest bottleneck. For a single user
application, I suppose classic is OK, though the lock management
code is certainly overkill.
words, but that's also overkill), we'd be better off abandoning
the current classic architecture and putting our effort into
fixing the glaring problems with the server architecture, then
creating a subset, in-process library for embedded use.
Regards,
Ann
www.ibphoenix.com
We have answers.
>First, the classic is somewhat easier to port,I've seen the evidence of that, but suspect that it has more
to do with the build procedures. Classic retained build
procedures from a time when InterBase ran on dozens of
platforms. Superserver started as a windows-only thing
and the builds we inherited ... I guess I don't have to
say more.
Classic is inherently less portable because it uses inter-
process communication and shared memory Until quite recently,
Unix/Posix had enough different ways of handling those that
most implementations were both compliant and incompatible.
>and we were not very luckyAs above - the threading primitives are simpler and and
>to make the super server work on some platforms.
more consistent than the combination of signals and
shared memory, so the problems are more from the build
(I think) than from the architecture.
>differences in implementation of threads among platforms make thingsNo doubt
>harder,
>and it's very likely that SS will not be very reliable on someMaybe.
>platforms until we find a resolution, while classic would just work for
>majority of users.
>Next, it's true that SS has better potential to scale, but only aI guess no one would be surprised if I found the other half
>fraction of users would benefit from it. Actually, one half of our
>current userbase use FB as a personal database or as a workgroup server
>up to ten simultaneous connections (all that mostly on Windows). While
>CS (as is now) is ideal for embedded solutions, SS (as is now) is an
>overkill for such solutions.
of the user base more interesting. A shared server starts to
be a good thing at two users - the shared caches reduce the load
on the disk, which is our greatest bottleneck. For a single user
application, I suppose classic is OK, though the lock management
code is certainly overkill.
>So, although I would like to see only one architecture used (as anyone),In my opinion (I should probably start every sentence with those
>it's definitely a long run, that would require another codebase split.
words, but that's also overkill), we'd be better off abandoning
the current classic architecture and putting our effort into
fixing the glaring problems with the server architecture, then
creating a subset, in-process library for embedded use.
Regards,
Ann
www.ibphoenix.com
We have answers.