search

sky-uk / mite

Mite - A Python Performance Testing Framework
https://sky-uk.github.io/mite/
MIT License
25 stars 7 forks source link

Uncertainties about how the message flow works #5

Open aecay opened 5 years ago

aecay commented 5 years ago

I'm not convinced that the messaging between the various components currently works in the way it's supposed to. For instance, at https://github.com/sky-uk/mite#recorder the readme says "by defaul this will read off of the duplicators other outbound socket tcp://127.0.0.1:14303". But looking at the code, here and here, it doesn't look like any socket on 14303 is ever established.

aecay commented 5 years ago

OK, I've been talking more with Davide about this. (And also reading the part of the readme higher up the document where the 14303 port is discussed 😳)

I think that what we want is an improvement to the CLI in the following way: make the duplicator understand its out socket arguments in the same way that the stats/collector/recorder understand their in socket arguments. So rather than

mite duplicator --message-socket=X Y Z
mite stats --stats-in-socket=Y
mite collector --collector-socket=Z

We have (with the same semantics as above)

mite duplicator --message-socket=X --stats-in-socket=Y --collector-socket=Z
mite stats --stats-in-socket=Y
mite collector --collector-socket=Z

That way, it's manifest that the arguments must be identical for it to work. An additional step would be to make the CLI programs ignore irrelevant arguments, so that it would be possible to do:

MITE_ARGS="--message-socket=X --stats-in-socket=Y --collector-socket=Z"
mite duplicator $MITE_ARGS
mite stats $MITE_ARGS
mite collector $MITE_ARGS

Then our script is typo-proof. (This makes things simple for the case that's common for us, which is running the duplicator/collector/recorder all on the same box, with only the runners on separate boxes. The situation where each component is on a separate box will be more complicated, but that would always be true...)