Appserver and DB server on different plateforme

Yes, this is perfectly possible.. Not recommended, but definitely possible.

If performance is a serious objective then this is generally a very bad idea.  Not because of the two different platforms but because you are putting the network in the way.  This will introduce signifcant latency and performance degradation.

When the app server and the db server are on the same server data access can be via shared memory.  Shared memory access is measured in nanoseconds.  Accessing the same data across a network connection is in fractions of a second.  That means that data access is literally millions if not billions of times slower.  (Network access is slower than even disk IO.)  This is sometimes unnoticable in small environments with small amounts of data and limited contention for resources (like a development environment).  But as soon as it goes to production it becomes a very big problem.  The sort of problem that gets people hopping mad.

One situation where it might make limited sense is when you have some very special APIs that are only supported on a particular platform that does not happen to be your db server platform.  If that is the case then you might configure an app server to support those APIs -- but be very careful to keep it focused on that API work.  You might need a two stage process for that where data access is done by an app server on the db box and then passed to the API box.

Thanks for your answers Kevin and Tom,

But could I object you, Having in mind some j2ee technical archi, that some market/customer applications apply this technical manner:

j2ee farm DB-cluster

Of course, it's possible having all installed on the same machine, but for large DB (millions of records...with big objects...), dedicated DB plateforme enhance performance to specific query requested.

This part is a huge time consumption. don't agree ? And for application server, some client requests don't need DB access...

In fact, I'm new in the wolrd of Progress OE products. I'm studying intensively things and I try to understand using my j2ee experiences...

Tom, you matched it when you wrote:

<<

This is sometimes unnoticable in small environments with small amounts of data and limited contention for resources (like a development environment).

>>

this is my case: I have 20 developpers, working on one dev environment: It's a confusing situation. All day long server (IBM P5, 8G ram, AIX 5.3, using partioning) have performance problem. My purpose is to change that making them using appserver on their own personnal computer and DataBasesss on several Linux server...Then, IBM server used only for developement consolidation.

What's your thought with this new lighting ?

Thanks.

Mo.

I think that you are going to make things much, much worse by trying to force Progress into a mold that fits a very different environment.  Progress is not a J2EE environment and trying to make it look like one will be a disaster.

I think that you should engage an experienced Progress performance consultant to come in, review your configuration and make recommendations.  If you need ideas on where to find such a person feel free to contact me

Thanks a lot Tom,

But as you can imagine situation is not so obvious as it may sound... It's a small but heterogeneous IT system and Progress OE is only a part of it. I try to solve problems step by step...

Of course, it could be the pretext to visit us in France...

Mo.

As it happens I will be in Europe in early November.  So that might work out.  Contact me offline if you want to setup an engagement.

My first thought is that your first step should be to insure that you are getting all the performance you can out of the system you have or, if there is some limiting factor in the existing system as too few disk spindles or whatever, that you get that identified and fixed.  It is highly likely that the existing performance is not optimal unless you have high quality tuning expertise on staff ... which I doubt or they would have told you the same thing Tom did in his initial response.

If it should turn out that the performance requirements exceed the existing system or minor changes to the existing system, then the second step is bigger iron ... unless it is the case that this application has multiple subsystems.  In that case, it could be reasonable to have more than one machine, each with its own AppServer and database, providing the services needed to support one or more subsystems.  Depending on the nature of the application, this might require introducing a messaging bus to coordinate the subsystems or it may be that you can simply get away with a few AppServer to AppServer calls to do that.