Re: Connection pooling + WebObjects
Re: Connection pooling + WebObjects
- Subject: Re: Connection pooling + WebObjects
- From: Chuck Hill <email@hidden>
- Date: Mon, 12 May 2008 10:51:49 -0700
On May 12, 2008, at 10:11 AM, Mike Schrag wrote:
Can any one advise me what is the difference between :
* Deploying Multiple Instances of a WebObjects application from
deploying a WebObjects application with Connection pooling
configured.
i.e., I have a WebObjects app, now I will deploy this app with 5
instances (or) I configure my WOApp with Connection pooling having
max 5 connections and deploy it.
They will behave differently. They will scale differently in
response to loads, depending on what your app does. Deploying
multiple instances is the normal way to go. Personally, I would
only use connection pooling in combination with multiple instances.
Chuck and I disagree here :) This is entirely presuming you're
using Wonder:
I think it can be a bit more complex...
If you turn on multiple EOF stacks in Wonder, you get most of the
benefit of being in a single stack, but without having to deal with
all the complications of being in multiple instances.
But you can also really increase the memory footprint. This entirely
depends on what is happening in your application. If your users
primarily only work data specific to them, then you should not notice
too much of a difference. If your users work on shared, large data
sets then the JVM memory needs are going to increase. This is not an
argument for multiple instances, but it is something to be aware of as
it reduces the number of instances you can run on one machine.
It also very much depends on if your apps have EOF as the bottleneck,
or if some other processing is the bottleneck. If EOF is not the
bottleneck (and it is for most of us), then multiple instances is the
only thing that will help.
I am not sure what you mean by "the complications of being in multiple
instances". Stack / instance synchronization or not, you still have
to handle optimistic locking errors. You have to handle them less
frequently if you are synchronizing, but they still have to be handles
(or ignored because they happen less frequently if you so choose...).
One thing that gives me pause with respect to multiple, synchronized
stacks is that is an an added layer of complexity on top of the
already complex concurrency issues. While I trust that you (Mike)
have soundly tested this, it adds complexity for a reduction in the
frequency of needing to handle something that I must handle anyway.
It seems to me that multiple instances are simpler in this respect.
It also adds processing overhead for every possible case of an
optimistic locking conflict, not just the ones that actually matter.
I don't have a clear idea on how that affects the balance of this
equation.
In most WO apps, scaling problems are due to the single EOF lock.
Multiple stacks alleviates this to a large extent, and for me would
be my first choice for the _scaling_ aspect. There are, of course,
border cases where you have to be careful -- Miguel recently ran
into this, for instance, where if you are using Wonder's eof stack
synchronization, it will synchronize the snapshots of inserts into
each stack, but if you're inserting a lot of "write-only" data, you
can leak snapshots (because they insert with a refcount = 0). But
there are some new API's to control this if this presents a problem.
For your "average" WO app, this should basically just work (barring
being really nervous like Miguel :) ).
Where multiple instances is really a win is 1) if you DO have a
problem in your app instance, you don't bring down the entire app.
So multiple instances gives you VM isolation (like an
OutOfMemoryError, for instance). 2) If you want fault tolerance, you
should be deploying on multiple machines, in which case you would
have to use multiple instances to take advantage of that.
Now, Wonder also provides remote EOF synchronization across multiple
instances (which behaves SIMILARLY to stack synchronization), but it
does come at a cost -- increased complexity, for one (even though
it's only a couple configuration Properties, it increases "the
things that can go wrong" quotient) and also it increases network
traffic between your boxes (by default it uses multicast
notifications between your instances to track changes).
So anyway, if you're having scaling problems and you want the
fastest way to a solution with the least amount of trouble, adding
stacks is probably it. If you want fault tolerance on top of that,
then multiple instances is the way to go.
Yes, if you are having scaling _problems_, I try out multiple stacks
and study how the affect your app. If you are simply planning a
deployment infrastructure, go for multiple instances first.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden