On 12 Jun 2002, Wes Felter wrote:
> I'd like to create a workload similar to srvlb-l4-4 but with
> multiple HTTP server agents on one physical host. The obvious way
> to do this is to add an addr_space entry to TheBench.server_side,
> but apparently the (undocumented?) SrvLb4As addressing scheme
> prohibits this. What's the justification for this restriction and
> is there a way to change it?
SrvLb4As simply returns server_side.hosts for server-side agent
addresses. Please try specifying all server agent addresses in
TheBench.server_side.hosts array and let me know if that does not
work. You will need to create those IP addresses manually. See
http://www.web-polygraph.org/docs/userman/address.html
If you want Polygraph to create server IPs run-time, you cannot lie
about the number of hosts you have. You will need to leave hosts as
is, set vipMap.addresses to whatever addresses you want to use
(instead of calling the serverAddrs() function), and adjust
server_side max_host_load and max_agent_load to match your
environment. Then, Polygraph will be able to create server-side
addresses run-time. Note that all hosts must have equal number of
agents for the alias creation code to work. See, again,
http://www.web-polygraph.org/docs/userman/address.html
And here is the justification you asked about:
SrvLb4As addressing scheme uses hosts field instead of addr_space for
server-side address selection. The scheme assumes that you want to
know the exact server addresses and control server placement since you
have to type those addresses in your load-balancer configuration file.
When the exact knowledge/control is needed, we use explicit settings,
such as hosts array.
Address spaces, on the other hand, are used to select a required
number of addresses from a given set, often using a sophisticated
selection algorithm that is difficult to track or reproduce manually.
The number of addresses selected is also not known in advance (e.g.,
it depends on user-configurable request rate) when "spaces" are used.
If you can think of a way to improve the current approach, please let
us know.
Thank you,
Alex.
This archive was generated by hypermail 2b29 : Mon Feb 06 2006 - 12:00:23 MST