2

I want to upload a unique file every time a VUser script is ran (as in the # of vusers in the Controller scenario) and I found some examples on different forums and out them together to try to accomplice this task:

Action()
{

char command[100];
sprintf(command, “copy C:\\source_dir\\srcFile.txt C:\\source_dir\\srcFile-%s.txt”,              
lr_eval_string (”{iteration_number}”));
system(command);

web_submit_data("FileUpload",
"Action={URL}",
"Method=POST",
"EncType=multipart/form-data",
"TargetFrame=",
"RecContentType=text/html",
"Mode=HTML",
ITEMDATA,
"Name=File", "Value=C:\\source_dir\\srcFile-%s.txt", "File=yes", ENDITEM,
LAST);

sprintf(command, “del C:\\source_dir\\srcFile-%s.txt”, lr_eval_string (”{iteration_number}”));
system(command);

return 0;


}

However this script does create 100 files each time and that is not what I want to accomplice. 1.How can I modify my script to create 100 unique files (once). 2.Then run the upload (web_submit_data function) once per VUser in the controller. 3.And then delete the files in the end?

Maybe put the file generation in the init and the file deleting in the end part of the VUser script?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Magnus Jensen
  • 905
  • 6
  • 36
  • 73

2 Answers2

2

You have a couple of options.

  1. You can pregenerate all of the files you need during the test and then pass in a fully qualified filename as a unique parameter to the virtual user script. IF the file is located on the load generator then you will have some read contention to deal with which will impact your virtual users as they all compete for the read head on the drive. If the files are on network attached storage then you also would take a hit to move the file across the network to your load generator and then again out of the generator for upload. You can dramatically improve the read access if you place the files on a small secondary drive, an SSD, by themselves, for the duration of the test.
  2. You can create the files on the fly. (a) Define random file size (b) Define random file name (c) write file in the local context (d) Use file in script for upload (e) delete file. All of this would be in the context of an iteration, assuming that the files uploaded needed to be of a unique file name and size for each iteration of each user. For this you have to violate a lot of best practice rules on the use of the hard disk during the performance test. You will have tens? hundreds? of virtual user threads all contending for access to the local disk subsystem which is generally a recipe for slowing down all of the virtual users as CPU is sent for high priority I/O interrupt tasks and away from user processes, plus the inevitable wait on the read/write heads for the hard drives as your threads create|write|read and then delete the file. You will need more load generators for this model and you absolutely need a reference control generator running a single user to check for imposed response skew from the test bed.
James Pulley
  • 5,606
  • 1
  • 14
  • 14
  • Ok. I will go for your first suggestion. You actually advise me to store all my pregenerated files on an external disk, connect it to the controller or load generator, and in my script refer this external disk (in the parameter settings in my script), right? – Magnus Jensen Feb 24 '13 at 19:17
  • External disk would be even slower unless you are using ESATA. The fastest method local would be to use an internal SSD as a second drive on each load generator. Store your pregenerated files on this second internal hard drive and then use a parameter file to pass in the information on the filename and location to the script. I am assuming you will be monitoring the load generators closely during the test for any skew on the test and you will have at least three load generators (two for primary load, one for control). You very likely will need more load generators – James Pulley Feb 25 '13 at 13:22
  • @JamesPulley, +1 Good advice regarding hard-disk bottlenecks. – Pacerier Jan 03 '15 at 07:12
1

I think your script is almost there. The problem I see is that you don't have a unique enough file name for the file you are creating. Each of your 100 users will start with the same iteration number.

You can try something like this, create a new parameter in the script's parameter list called 'vuser' and assign it the type 'Vuser ID'. This will populate as the number of the individual vuser when you run it in the controller. This will ensure your users don't step on each other while using the file. Add this to your file name like this:

sprintf(command, "copy C:\\source_dir\\srcFile.txt C:\\source_dir\\srcFile-%s%s.txt,              
lr_eval_string ("{iteration_number}")
lr_eval_string ("{vuser}") );

This will work as long as all your users are in the same group in the Controller. If you use this across multiple groups then do the same thing by adding a 'Group Name' parameter to the file name.

Nathan
  • 341
  • 1
  • 4