Locust: Badly named commandline argument --host

Created on 4 Jul 2020  ·  6Comments  ·  Source: locustio/locust

The host argument is confusing and misleading.
1) What host? There are multiple host involved, the master, the slaves and the host running the application to be tested.
2) The value is a URL not a hostname!

Better names would be --url, --url-to-test or --test-url, dependig on how verbose you want to be.

feature request non-critical

Most helpful comment

I agree that it's not a very good name, and I think target is better. When/if we change this, I think we should make both options work with a deprecation warning for a few versions before we completely remove --host just to avoid breaking stuff for people.

All 6 comments

It would make sense to change it to url (but then we'd need to fix the issues linked, because url kind of implies that you should be able to specify more than just protocol:host, which is currently not the case)

Maybe this is just target. Maybe it is not actually always a URL, e.g. if you are not doing HTTP test. I do think host is misleading, and it is also unfortunate that LOCUST_HOST means the test system, even if you are supposed to mentally strip the LOCUST_ from the environment variable.

I agree that it's not a very good name, and I think target is better. When/if we change this, I think we should make both options work with a deprecation warning for a few versions before we completely remove --host just to avoid breaking stuff for people.

The docs mention the host option:

-H HOST, --host HOST Host to load test in the following format:
http://10.21.32.33

If this is the same thing discussed here, i.e., host actually implies the target of the test (the app under test), than does it mean that the example of docker-compose.yml for testing with multiple workers (below) should be setting --master-bind-host http://master:8089 instead of -H http://master:8089:

version: '3'

services:
  master:
    image: locustio/locust
    ports:
     - "8089:8089"
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --master -H http://master:8089

  worker:
    image: locustio/locust
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --worker --master-host master

I tried to replace master with my localhost (below) and it results in workers not being able to connect to the master:

version: '3'

services:
  master:
    image: locustio/locust
    ports:
     - "8089:8089"
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --master -H http://127.0.0.1:8089

  worker:
    image: locustio/locust
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --worker --master-host 127.0.0.1

I have realized a few things about the way docker-compose works -- the names of the services can be used as DNS. With this knowledge the question would be a bit different and consist of two parts:

  1. If -H denotes the service to be tested, then shouldn't the example in the docs be something like:
services:
  web:
     image: myservice
     ports:
      - "8000:8000"
  master:
    image: locustio/locust
    ports:
      - "8089:8089"
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --master -H http://web:8000
  worker:
    image: locustio/locust
    volumes:
      - ./:/mnt/locust
    command: -f /mnt/locust/locustfile.py --worker --master-host master
  1. Is there a way to docker-compose original example, and run my service outside of the docker-compose context. and point the workers to it (i.e. not adding my service to the compose file as in 1.)?
Was this page helpful?
0 / 5 - 0 ratings