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