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
|