Use different .csv file for each core agent for Visual Studio Cloud Testing.

We are going to execute simple REST API load test with Visual Studio Cloud Test
Request contains authorization token and we are using existing .csv data source to supply them.
The test is running fine from local machine but from cloud 97% of tests are failing.
Because there is concurrency check in our services that is One token can be used to make only one request.
My test is running from 25 agent machines in cloud and all of them are using the same .csv data source.
Is there is a way to spread the different data sources per cloud agent?
Thanks in advance.

Comments

  • As per your comment, the data source access method of unique cannot be used with a VSTS CLOUD load test.

    One possibility: Can the tokens you generate include the agent number (AgentID) ? If yes then you might use a plugin containing code based on:

    string tokenFromCSV = e.WebTest.Context["DataSource1.file#csv.token"].ToString();
    string agentId = e.WebTest.Context["AgentId"].ToString();
    if(agentId.Length==1) agentId = "0" + agentId;
    string tokenToUse = tokenFromCSV + agentId;
    e.WebTest.Context["tokenToUse"] = tokenToUse;
    Then in the places that currently use the token from the CSV file, use the newly written context parameter tokenToUse. There are many other ways that the agent-id could be merged into the token value.
    Another possibility. If there are never more than 20 (or some other not-too-large number of) agents used then generate a CSV containing 20 columns of token values. Have the column names contain the agent number and then let each agent only use the values from its column. This would probably need a plugin to access the correct column and store the value into a context parameter.
    Another possibility. If the number of lines in the CSV can be several times bigger than the number of virtual users in the test. I am thinking of at least 10 times as many, but the bigger the ratio the better. The set the CSV access method to Random. The tests should then mostly run with tokens only being used by one test at a time. There will be some dual uses and hence test failures but your customer might accept that level of failures.

Sign In or Register to comment.