Questions regarding WPG

Alex Rousskov rousskov at measurement-factory.com
Tue May 9 20:53:13 UTC 2017


On 05/09/2017 10:19 AM, Nagaraja Gundurao wrote:

> * Is there a way to have only some number of the configured robots be
> active at any point in time? And, have this active set change over time,

Yes, see populus_factor_beg and populus_factor_end in PGL Phase
object[1]. You can build arbitrary population growth/decline patterns by
scheduling[2] appropriately configured test Phases. For example,
PolyMix-4 workload uses[3] that feature.

[1]
http://www.web-polygraph.org/docs/reference/pgl/types.html#type:docs/reference/pgl/types/Phase

[2]
http://www.web-polygraph.org/docs/reference/pgl/calls.html#call:docs/reference/pgl/calls/schedule

[3] http://www.web-polygraph.org/docs/workloads/polymix-4/#Sect:3.1


> so we can cycle through all configured robots?

This aspect is different from the two aspects you have mentioned above.
The Phase-driven test schedule does not focus on which configured robots
are used. It focuses on the number of used robots. For example, there is
currently no way to use 10% of maximum robot population at any given
time but eventually use all configured robots. If you describe the
details of your use case, and the desirable parameters, we would
consider adding support for it.


> * Is there a way to stitch together WPG log files from a number of
> different WPG clients?

Yes, both Polygraph reporter and lx tools merge all given logs
automatically by default. This merging was designed for concurrent
client runs within one test, but it may work for sequential runs as
well, especially if there are no gaps between tests. If something does
not work well when you merge, please discuss.


> * In our lab setup, we tested configuring .pg file and found out the
> max. robots that could run from a single .pg file to be 3000 robots per
> vm.  Do you agree?.  Is it dependent on PC/vm or WPG limitation?.

There is no artificial limit on the number of robots. The practical
limit heavily depends on your hardware, OS, their configuration, and
Polygraph workload.


> * Can the reports be generated if we have only Server side logs and WPG
> client is not run(client will be another tool).

I believe so. Naturally, client-dependent stats will not be available.



> Here are some error messages we saw and need some explanation on when it
> occurs and what are it’s effect on overall performance/report.


> OLog.cc:118: soft assertion failed: theZStream->write(buf, size)
> OLog.cc:118: (s11) Resource temporarily unavailable

Polygraph cannot write its test log file. Perhaps there is something
wrong with the log storage device? It is supposed to be reliable. Are
you using some kind of network-dependent storage that may get
overwhelmed with log and/or test traffic and fail?

Test log corruption is likely until you fix this unusual problem.


> 000.72| Xaction.cc:112: error: 4/4 (c14) premature end of msg body

> 000.83| Xaction.cc:112: error: 1/6 (c15) premature end of msg header

These custom Polygraph errors are documented[4].

[4] http://www.web-polygraph.org/docs/reference/output/messages.html


> 013.34| Connection.cc:701: error: 3/225 (s104) Connection reset by peer
> 013.34| error: raw write on SSL connection failed on connection with
> 10.0.26.170:21521 at 3 reads, 159 writes, and 1 transactions

This is a standard system call error -- Polygraph could not write(2) to
a TCP socket when talking to an SSL peer (because the peer closed the
connection or disappeared). The affected transaction will be counted as
failed, of course.

Such errors are possible if HTTP agents have mismatching persistent
connection settings/defaults, leading to HTTP race conditions. If you do
not use persistent HTTP connections or carefully configure them to avoid
race conditions, then the peer that closed the connection prematurely
should know why it did that.


> AddrParsers.cc:31: soft assertion failed: defaultPort >= 0

This is either a Polygraph bug or some kind of PGL misconfiguration.
Need more info to classify: Does this happen at startup or during a
test? Just once or many times? Is this problem easy to reproduce?


HTH,

Alex.



More information about the Users mailing list