Csv not being read in sequence

[eoinyoneill]

I am using CSV files to store unique values to be used just once in a URL for GET's and PUTs.

But the CSV file is not being read in sequence at all. some rows are being duplicated and some are not being used at all.

out of 200 unique values only 120-130 are being picked up uniquely

using artillery 1.6.1 on node14

snapshot of what is being used. I know this is not runnable code, but just took the areas where I was calling the fields and using them. input csv file inputcsv.txt

output from artillery: output.txt

sorted xlsx file with input csv ordered against output csv ordered: Input vs output order.xlsx

payload:
    path: "../inputcsv.csv"
    fields:
      - serialNo
      - triggerText
  order: sequence

- get: 
          url: "/xxx/{{serialNo}}/{{triggerText}}"

[hassy]

It's probably Github's formatting in the code sample, but could you make sure that output is on the same level of indentation as the rest of the options?

I can't reproduce the issue with the same version of Artillery. Here's my test:

config:
  target: "http://localhost"
  phases:
    - arrivalRate: 10
      duration: 20
  payload:
    path: "./inputcsv.txt"
    fields:
      - serialNo
      - triggerText
    order: sequence
scenarios:
  - flow:
      - log: "{{serialNo}}"

Which I run with:

artillery run -q test.yml > output.txt

And then to compare input lines with output:

diff inputcsv.txt output.txt

which shows no difference.

[starnetdev0]

Hi, I have seen the issue happens when artillery is run with multicore options, in example: MULTICORE=true ARTILLERY_WORKERS=6 ./node_modules/artillery/bin/artillery run --output ./reports/report.json config/config.yml Each process executed in each core is taking the same record from the payload file. I have tested it with version 1.6.2.

[ichbinsteffen]

Maybe I'm late to the party here but I discovered the same problem. I noticed that when I use very large numbers in the CSV file (beginning with 80000202000000000 and 10k upwards) it goes in steps of 10, sometimes 20 instead of 1.

Today I found out why: Artillery parses and casts the contents to a type by default and thereby has some problem casting very large numbers. If you suppress casting, like this:

payload: path: "./numbers.csv" fields: - "sequenceNumber" order: sequence cast: false

It treats the content as it is and wont have this problem.

[luislhl]

Hello @hassy

I've experimented the same issue.

I've downloaded the same input file. This is my test:

config:
  target: "http://localhost"
  phases:
    - arrivalRate: 2
      duration: 2
  payload:
    path: "./inputcsv.txt"
    fields:
      - serialNo
      - triggerText
    order: sequence
scenarios:
  - flow:
      - log: "{{serialNo}}"

Run with:

npx artillery run -q test.yml > output.txt

This is my generated output.txt:

ff114d3e-0ec9-4c68-963a-9e2c93fac051
ff114d3e-0ec9-4c68-963a-9e2c93fac051
6befd7f3-8c74-4402-b668-1386ca4ee1a7
6befd7f3-8c74-4402-b668-1386ca4ee1a7

This is my version:

artillery/2.0.0-5 linux-x64 node-v14.16.0

If I use the same config file, but changing the phases to this:

  phases:
    - arrivalRate: 10
      duration: 20

I'll get the following output:

output.txt

By running again this exact config, I'll get a slightly different output:

output2.txt

I can also reproduce this if I change the input to simpler things, like just numbers in sequence, or if I use MULTICORE=false

[anbeck77]

I'm seeing the same behavior; it happens consistently on my DELETE methods for any count of requests, the first half will iterate through the list, and then return to the top, rerunning the paramterized DELETE signiture for an already deleted record. I haven't seen it happen for POST request.

This is pretty much eliminates the usefuless for performance testing DELETEs.

[shtlrs]

Hello @hassy ,

Let me start off by saying: Artilley is very cool, kudos on the work.

Second, I'm experiencing the same issue here when loading data from the csv.

Consider this setup

// flow.js

module.exports = { helloFlow };

async function helloFlow(page, vuContext) {
  const email = vuContext.vars.username;
  const password = vuContext.vars.password;
  console.log(email);
  console.log(password);
}

And the following manifest

config:
  payload:
    path: "users.csv"
    cast: false
    order: sequence
    fields:
      - "username"
      - "password"
  target: https://someurl.com
  phases:
    - duration: 90
      arrivalRate: 2
      maxVusers: 2
  engines:
    playwright {}
  processor: "flow.js"

scenarios:
  - engine: playwright
    flowFunction: "helloFlow"
    flow: []

users.csv

[email protected],redacted
[email protected],redacted

The logs look like this

| [email protected]
/ redacted
/ [email protected]
redacted
- [email protected]
redacted
/ [email protected]
- redacted
\ [email protected]
redacted
- [email protected]
\ redacted
- [email protected]
\ redacted
- [email protected]
redacted

The arrival rate here is 2, and max of virtual users I can have is also 2, doesn't that mean that for each VU that comes in, it should pick up data from one row ?

I'm saying this, because when I change the arrival rate to 1, for each virtual user created, they get a separate row of the csv, so it works pretty well then.