> At 12:13 PM 2/26/2001 -0700, Jason Wharton wrote:
> >I am aware that memory allocated to a server process is directly
> >proportional to the page size and number of connections to a database.
>
> Actually, it's not. The size of the page cache is settable, which
> removes the page size as a factor.

How is this accomplished?

> Connections are one factor, as
> are metadata size and complexity, request size, complexity and duration
> (i.e. when requests are unprepared), and for superserver, lock table
> size, and for superserver, the number of connected databases.

I feel like this is obscuring things a little and mine is over simplifying
things a little. Is there a chance we can meet in the middle for the sake of
a productive discussion?

> >In
> >the classic architecture this makes sense as each connection ends up

being

> >serviced by a separate process. This also explains why this architecture
> >doesn't feasibly scale to more than 256 concurrent users.
>
> Well, maybe yes, maybe no. Depends on how the operating system handles
> a large number of processes.

What kind of hardware and OS are we talking about here? For the sake of
discussion can we simply assume typical hardware that most people are going
to be using? Even better, low end worst case scenario hardware?

> >But, in the super-server architecture, connections are actually serviced

by

> >a single process such that allocated resources are shared in common

rather

> >than separated across process boundaries. What I am wondering is if the
> >resource allocation parameters are still the same or if there is a
> >difference such that new connections will cap out and not add additional
> >resource allocations.
>
> No. Every connection takes some amount of resources - I really don't
> know at the moment how much, but non-zero for sure. Each transaction
> also takes some amount of resources.

Right, that is a given, to some extent. I'm wanting to get a feel for how
much the SS architecture can be made to ease the hit of many more concurrent
connections than it presently allows. I feel like it would be much more
possible to move in this direction with the SS architecture than the
classic. I'm talking like thousands of concurrent users... Is it even
possible or would some sort of server array to pool the external connections
have to be implemented to accomplish that? I know almost squat about sockets
and limitations on how many pipes a network can have open at any given time.

> >What I am driving at is: With going to SS is it possible that resource
> >allocations can become more independent from the number of concurrent
> >connections such that the number of connections can significantly

increase?

> >What is the next point of exhaustion that would limit the number of
> >concurrent connections?
>
> Probably the fact that the lock table in superserver is not dynamically
> sized.

It is obvious I am going to have to do some homework on this. Could you give
me a brief description of the lock table, what role it plays, and how it
interacts as connections come and go?

Thanks,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <IB-Architect@yahoogroups.com>
Sent: Monday, February 26, 2001 12:31 PM
Subject: Re: [IB-Architect] Connection resources, classic vs. SS


>
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>