Ideas for parallell load testing DX

[Goffen]

Hi there! I really love Hurl and is using at my work a lot ot test our applications during CI. But we are also using for some performance testing. Because of the way our app works the performance of one hurl agent is enough to load it plenty.

I have an idea (related to #3786) for a simple way hurl would be even more useful for us.

Often times we have a scenario starting with:

• search for something / get a list of something
• do something with that item
• then ... a lot of other operations to follow on that first item

Using Hurls parallelisation it's impossible to get workers to use one item each - because they get the exact same variables.

So my idea is quite simple:

In worker.rs in parallel-module adding this:

let mut job_varibles = job.variables.clone();
let worker_index: i64 = worker_id
                .0
                .try_into()
                .expect("Way too many jobs if this overlows");
job_varibles.insert("JOB_INDEX".to_string(), Value::Number(worker_index.into()));

and supplying that to the run function gives the user lots of power. So now in a hurl-file I can use that variable and pick different items for each parallell worker.

I created a simple hurl-file + server to test this out:

GET {{host}}/job?index={{JOB_INDEX}}

HTTP 200

[Asserts]
jsonpath "$.index" matches "\\d"

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/', defaults={'path': ''}, methods=['GET'])
@app.route('/<path:path>', methods=['GET'])
def catch_all(path):
   # Use jsonify to return a JSON response
   return jsonify(request.args.to_dict()) 

if __name__ == "__main__":
    app.run(host='0.0.0.0', port=8000)

I can of course hack together a PR for this, but I have problem with my signing key. And I think the change is more of design decision than a coding exercise - because each worker thread parses its hurl-file so its really easy to get in.

[Goffen]

I can also use it to provide different files when uploading stuff that could also come in really handy.

[jcamiel]

Hi @Goffen

we've recently introduced function, a way to create dynamic data:

GET https://foo.com?id={{ newUUid }}

You can actually use it to give a unique id for each run even if it's the same file.

Also, when introducing function, we have "reserved" name starting with "newXxx" or "getXxx" so we could use it to implement something like this:

GET https://foo.com?id={{ getRunIndex }}

That will give you the index of the file ( similar of the job index but that will also work for sequential run).

In the same idea, we could add getEntryIndex to get the current entry index (see #847)

GET https://foo.com?id={{ getEntryIndex }}

[Goffen]

Yes that would be a very nice place to add it to.

But I would like to have the worker index. So when I spawn up 20 parallell workers, they can operate separately. I almost always have repeats / jobs to be divided evenly