Hmmmm, interesting the last paragraph, I don't know that.

Greetings.

Walter.

On Sun, Jun 5, 2011 at 1:50 AM, Helen Borrie <helebor@...> wrote:

>
>
> At 09:39 AM 5/06/2011, heineferreira wrote:
> >Hi
> >
> >How much does the memory usage differ between classic and super classic?
>
> Not much. Both models use separate DB caches per connection. There is a
> slight win for SC under some conditions, due to in-memory lock structures
> sharing space.
>
>
> >Yes I know the difference in architectures - I saw the diagram in the
> FAQs. It looks like super classic is a better option for smp.
>
> Why do you think that?
>
>
> >Super Classic was only recently released, so I am concerned about it's
> stability?
>
> Its stability will be the same as Classic. It's the same engine, deployed
> with its own listener daemon and some shared memory benefits, instead of
> using xinetd and running each connection in its own self-contained resource
> set.
>
>
> >Also, can you develop on super server and then deploy to super classic?
>
> Yes. Just make certain you reconfigure the DB cache appropriately for the
> SC deployment.
>
>
> >Any limitations about classic or super classic that I should know about?
>
> Don't try to use it on a 32-bit OS under production conditions. The idea of
> SC is to improve the engine's ability to use a well-resourced host machine.
> It cannot bypass the per-process memory limitations inherent in a 32-bit OS.
> The resources available to a 32-bit OS will soon be exhausted with multiple
> users, even if none of them is doing very much.
>
> ./heLen
>


[Non-text portions of this message have been removed]