Having problems with message search?
>>
However, our current model of recovering costs by tracking completes seems to
unfairly punish those that take time to author efficient scripts and manage
their projects well versus those that don't.
We try to deal with this by using
“total variables collected”, instead of completes. The idea
being that a longer study could equal that of 4 or 5 smaller ones.
>>
Regarding your customized load-balancing script, did you completely forgo the
other SPSS provided criteria with your per-engine session limits, or is that in
addition to?
Good question, I’ll have to look at the
other settings – it has been a while and I try to forget this sort of
info as quickly as possible. ;-)
With the default, we were finding the first
app server to be the most loaded all the time….and less responsive than
when the projects were more distributed across more app servers. Hence
the reason we tried to create a ceiling for each engine (of course, we can
change that ceiling on the fly).
Ideally – you’d want all
hardware sharing the burden on the load equally. Not one box handling 75%
of the load and the remaining 3 with 25%. I’m hopeful that 5.6
might take care of this a little better.
>>
Not to pry, but I was curious about your decision to go with virtual hosts with
only two VMs each.
We had 12 gigs to allocate to each virtual
app server. As you say, we could have split this into more virtual app
servers with less memory allocated to each.
In load testing, more virtual app servers
required more OS overhead (read: additional OS overhead for each virtual
server). It takes more effort for VMWARE to manage that many more OS’s,
plus we would take a memory hit by needing to allocate more RAM to each additional
OS. We wanted as much RAM as possible allocated to engines.
We decided to load up as many engines per
app server as we could on a single OS.
The virtualization is nice b/c we can
change the ratio of web to app servers if needed – though, so far, we
haven’t needed to do this (suspend app, load up web, etc).
In the second example, we’re trying
to figure out what the VMWARE overhead is by not using it. We’re
constantly trying to understand the complete cost with hardware/mgmt included.
In the second cluster, we’re paying less from our managed hosting
provider (with less hosts)…and we’re foregoing the vmware licenses.
Having 2 production clusters is nice because
we always have one to upgrade over an extended period of time.
Historically, we tried to do the “let’s upgrade it over the weekend”
plan…. and….that didn’t quite work out so well. ;-)
-David
From:
NADUG@yahoogroups.com [mailto:NADUG@yahoogroups.com] On Behalf Of Mike
Gates
Sent: Wednesday, September 10, 2008 3:12 PM
To: NADUG@yahoogroups.com
Subject: RE: [NADUG] Re: how many engines are you running on your
typical online/web cluster for mrinterview?
|
I
absolutely love the idea of capacity on demand, especially if we had the
ability to somehow track resource utilization by project. I realize
that the perfect formula for tracking stuff like this doesn't exist and/or is
overly complex. However, our current model of recovering costs by
tracking completes seems to unfairly punish those that take time to author
efficient scripts and manage their projects well versus those that don't. Regarding
your customized load-balancing script, did you completely forgo the other
SPSS provided criteria with your per-engine session limits, or is that in
addition to? Not
to pry, but I was curious about your decision to go with virtual hosts with
only two VMs each. As we take the more risky approach of hosting a wide
variety of VMs on ESX clusters, I was curious if you've stumbled across an
inherent flaw with the virtualization approach (other than the fact
that virtualization doesn't magically create server resources out of
thin air ;-). -
Mike
This setup is sitting on 4 physically
very large servers with a ton of RAM (not including DB Cluster). Each
physical server is hosting two virtual servers (1 web and 1 app) via VMWARE. We actually limited each engine to 50
interviews for a total of 1800, in an effort to better distribute the load
across all available hardware. The cluster doesn’t seem to bring
engines online when they should, so we often see the first app server
struggling the most unnecessarily….when the engines towards the end are
hardly used at all. This cluster has really performed
extremely well. The only time there are issues is with an occasional
project with a 13-20 meg MDD which seems to throw the cluster into a tail
spin every once in a while. Cluster 2 – verison 5.5: The other has 4 engines per app server
for a total of 8. This one has 2 physical web and 2
physical app (not including DB Cluster). We’ve limited each engine is to
200 per engine for a total of 1600 Both clusters are using Enterprise
versions of OS and SQL. We’re somewhat trying to
understand the best mix. The second cluster is to understand how this
performs without the VMWARE layer. What I’d really like to see is a
cloud solution, where I can deploy and suspend web or app servers on the
fly..attach them to the cluster when needed, etc.. Much like what http://www.gogrid. com/
does… The thing that stinks now is that I have
to plan for the peak loads, which is extremely difficult to do with
mrinterview (as it entirely depends on the mix of projects, the size of the
MDD files, and so on). It would be great if I could pay for capacity on
demand like a utility. I bet we’re only a few years away
from this.
-David From:
NADUG@yahoogroups. com [mailto:NADUG@ yahoogroups. com] On Behalf Of ko_mike.gates --- In NADUG@yahoogroups. com, "Zotter, E. David"
<david@...> wrote: |
Offline 
Send Email