Its very nice to hear your advises and discussions.
Thanks for all your inputs.
We have 3 app servers of which 2 act as webservers as well and 1
separate database server, all are of Solaris 9 OS.
We do NOT have Project Wonder integrated to our app.
Currently we have 100's of instances configured for our applications and
is running LIVE.
At times we have 30,000+ users accessing our application during business
hours of a day and at these times, we are forced to restart our
applications/ servers many-a-times to serve better. There are different
users accessing different sets of data at different times. We become
NERVOUS, REST-LESS and LOST at these times. Its lot of pain hearing
complaints from users of application about app slow-down, inaccessible...
As per your advises, we will explore Connection Pooling and ERX Multi
EOF stack(* Any one helping us to quickly integrate just this ERX thing
Mike talking about, would be greatly appreciated.* ).
So, we are looking at different solutions to make our app better for
users. In this path, we are trying to fix performance issues and modify
app architecture where necessary....
Please advise.
Thank You
Shravan Kumar. M
effigent India Pvt., Ltd.,
----------------------------------------------------------
On May 12, 2008, at 5:13 PM, Mike Schrag wrote:
Is this implemented through "object store coordinator pooling"? I
was wondering about that recently.
Yep ... It's actually the same plumbing as multiple instance
synchronization, to shuffle the data around with the exception that
in local syncing, it can actually inject the snapshots directly into
the pooled EODatabases. In Wonder, it does a round robin of your
OSC, but (if i recall) associates a session with an OSC (if there is
one) and a thread with an OSC. So once you have a session, you stay
on a particular OSC, and for a particular thread, once you start
performing operations, your thread will stay on that same OSC, to try
to minimize oddities of ending up with two EO's from two different
stacks, etc. As far as the injecting of snapshots, this is a
blessing and a curse ... I mentioned it in the previous post, but
when we inject the snapshot, it has a refcount of zero. In EOF,
snapshots only get released when the DROP to zero. There is no
reaper thread for the snapshot cache. This means that if you push a
snapshot to another EODatabase that is never fetched into an EC in
that OSC, it will never get released. I recently committed some API
to control this (so you can turn off snapshot syncing per-OSC and
just do GID-based notification). For many apps, you'll never notice,
because most data is touched multiple times, but server types of apps
(with bulk imports of read-mostly data, for instance), might be an
issue. Remote syncing does not have this problem, because it's
already GID-only.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-deploy@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
