You asked about connection counts...

We're not currently running high connection counts, but part of that is
because we've intentionally treated them as a scarce/expensive resource.
Here are the reasons that have impacted our decisions:

(1) Connection counts were associated with seat license counts, and we
needed to keep things cheap. This is obviously going away with 6.0, but it
kept us from building in more multi-threading into our application because
each thread requires a separate connection (Local Interbase 4.0 only allowed
4 connections, and we needed all of them for separate processes). Now we
really need to build in some strong multi-threading, so we're going to start
eating up connection counts.

(2) We are using the BDE (for better or worse).

(3) It takes a long time to get a connection. Consequently we hate to drop
it. We specifically added code to make sure the connection stays alive
because the delay to (re)open a connection as needed was killing
performance.

In terms of future plans, we have to support a wide variety of customer
deployments. Everything from a single system managing one store up to a
central system managing thousands of stores. For the high end, we're being
forced into middleware situations, so I doubt that we're likely to need more
than a couple hundred connections anyway. But then, we're targetting
Interbase for the low end, not the high end - and for the low end I probably
only need 5 to 25 connections.

It might be interesting to look at using the Interbase APIs versus the BDE,
but I can't (at this time) focus that much development effort on optimizing
Interbase. We need to support other platforms too, and the BDE does that
for me.


-----Original Message-----
From: Markus Kemper [mailto:mkemper@...]
Sent: Tuesday, May 30, 2000 9:53 AM
To: interbase@...; IB-Architect@egroups.com
Subject: [IB-Architect] Re: 'approximately' 400 user connections



Don & others with high user counts,

I would like to understand from a application/developer
perspective the real need for high user counts is. Thus I
am suggesting that we move this discussion to the Architecture
list.

In almost all of the high user counts scenarios I've
encountered the need has been perceived vs. technically
needed.

Case 1:

Connections Supported [ n ]

This in my mind is a marketing thing. A developer has a
system in mind and is evaluating InterBase thus, they look
for a feature/functionality statement that says we support
[ n ] connections.

I have found that this is more of a perceived need rather
than a technical one. Meaning that someone wants the ability
to connect at 6am (or when they get to work) and leave the
app open all day regardless of whether any real processing
is going on. So the fact that there might be a 1000 employees
gets translated into the need to support a 1000 connections.
I consider this the lazy application. The reality might
actually be that only 200 users are really accessing the
server at one point in time.

I'd rather see an application designed so that it maintains
a connection to the server only when working with data.
Perhaps some optimization of connection performance would
help here.

Case 2:

Something like the BDE is involved. Meaning that an application
has to have mutliple connections to perform a task. Thus, a
100 user system might require 2 to 3 hundred connections.

This can often be resolved by using multiple transaction per
connection capability found with the API, IBX and/or IBO.

Case 3:

As an example, consider a robot driven assembly line system
where there are a 1000 robot running 24x7 capturing data.
If a 1000 live connections is required to make this possible
perhaps IB is not yet the server for this application. Such
a system could be designed with InterBase (ie. batch processing).
How common are these applications? The applications that
actually 'require' 1000 live and conncurrent connections?

I'd venture to guess the the most common scenario is the
scenario described in case 1 above and that case 3 is not
very common.

Currently, if the 'real' connection need is in the range of
100 - 150 I suggest that a developer pay very close attention
to the behavior (transactions, query optimization, idle
connections, etc) and also begin to consider looking at a
middleware technology.

If the 'real' connection need is beyond 150 I strongly suggest
looking at a middleware solution.

It bothers me when developers view a connection and its resources
as expendable. Too many times have I seen a developer create
an application on their desktop machine where performance is
always more than acceptable and then deploy it into a medium
or large environment based on a marketing 'connections supported'
claim and see it fail or run slow.

So I ask, where is the 'real' need?

- Better raw connection performance?
- Better documentation/education on how to design an application
so that it utilizes the servers resources most appropriately?
Meaning instruction against idle connections.
- Develop a connection manager type of application that is cross
platform and specific to InterBase. Perhaps the Guardian
could be utilized for something like this?
- Enhance the servers ability to manage large numbers of idle
connections.

Markus

> >Enterprise applications usually have some form of middleware to manage

the

> >database connections. (and overcome some of the other limitations caused

by

> >factors outlined above.) An n-tier solution is the recommended way to

go.

>
> We run an older version of Interbase (4.0) on HP_UX and support up to

200 -

> 250 users just fine. As has been reported, it is not just the db, but all
> the other layers that create "perceived performance". And I have heard

that

> even 5.x made better use of the lock table, and hence might squeeze some
> more life out of it for us moving off of 4.0.
>
> I also feel Interbase will be hindered as to it's further growth with
> this limit. Sure, it's easier to manage than the bigger db's, but remove
> this hurdle and you might really have something! I really like parts of
> Interbase, but with us hitting the limit, it's cost us thousands of

dollars

> to build work-arounds (buying extra hosts, re-configuring an entire
> application system to be split over multiple hosts, all cause of

Interbase).

>
> As far as the comment about n-tier solution solving the issue, I find it
> odd that the db does not handle this load out of the box, and that you
> should have to implement another layer of technology to get around it.
> Course, maybe that is just my mainframe background showing, but this is

not

> a lot of users (250). BTW can you give me some examples of n-tier

solutions

> to get around it when your application systems has it's programs running

on

> HP_UX? I'd be curious if we missed something big in our adventures over

the

> last few years.
>
> PS We are anxiously waiting to explore Interbase 6.x when our var moves to
> that platform. 8*)
>
> Thanks.
> ------------------------------------------------------------------------
> Don Malzahn, IT/AS, Harper Community College Voice:(847) 925-6829
> E-mail: dmalzahn@... Web page: http://www.harper.cc.il.us
> "Example is not the main thing in influencing others, it is the only
> thing." - Albert Schweitzer
>
> _______________________________________________
> Interbase mailing list
> Interbase@...
> http://mers.com/mailman/listinfo/interbase

------------------------------------------------------------------------
Best friends, most artistic, class clown Find 'em here:
http://click.egroups.com/1/4054/4/_/830676/_/959706142/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com