2013-02-20 2 views
2

Я хочу загрузить уникальный файл каждый раз, когда запускается сценарий VUser (как в # из vusers в сценарии Controller), и я нашел несколько примеров на разных форумах и их вместе, чтобы попробовать чтобы соучастник этой задачи:loadrunner uplod уникальные файлы с каждым VUser

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; 


} 

Однако этот сценарий действительно создает 100 файлов каждый раз, и это не то, что я хочу соучастник. 1. Как я могу изменить свой скрипт для создания 100 уникальных файлов (один раз). 2. Затем запустите загрузку (функция web_submit_data) один раз на VUser в контроллере. 3. И затем удалите файлы в конце?

Может быть, поместить генерацию файла в init и удалить файл в конце скрипта VUser?

+0

Также см. Https://groups.google.com/d/msg/lr-loadrunner/dk1ojhjP06A/hioxhi6zjeIJ – Pacerier

ответ

2

У вас есть несколько вариантов.

  1. Вы можете предварительно создать все файлы, которые вам нужны во время теста, а затем передать в качестве уникального параметра сценарий виртуального пользователя в качестве уникального параметра. Если файл находится в генераторе нагрузки, тогда у вас будет какое-то мнение о том, как это повлияет на ваших виртуальных пользователей, поскольку они все конкурируют за чтение на диске. Если файлы находятся в сетевом подключенном хранилище, вы также можете получить удар, чтобы переместить файл по сети в ваш генератор нагрузки, а затем снова из генератора для загрузки. Вы можете значительно улучшить доступ для чтения, если вы поместите файлы на маленький вторичный диск, SSD, самостоятельно, на время тестирования.
  2. Вы можете создавать файлы на лету. (a) Определить размер случайного файла (b) Определить случайное имя файла (c) записать файл в локальном контексте (d) Использовать файл в сценарии для загрузки (e) удалить файл. Все это было бы в контексте итерации, предполагая, что загруженные файлы должны иметь уникальное имя и размер файла для каждой итерации каждого пользователя. Для этого вам необходимо нарушить множество правил лучшей практики использования жесткого диска во время теста производительности. У вас будет десятки? сотни? из виртуальных пользовательских потоков, все из которых претендуют на доступ к локальной дисковой подсистеме, которая, как правило, является рецептом для замедления всех виртуальных пользователей, поскольку процессор отправляется для высокоприоритетных задач прерывания ввода-вывода и от пользовательских процессов, а также неизбежного ожидания на читать/записывать головки для жестких дисков, так как ваши потоки создают | писать | читать, а затем удалять файл. Вам нужны больше генераторов нагрузки для этой модели, и вы абсолютно необходим генератор опорного управления работает один пользователь для проверки введенного перекоса ответа от испытательного стенда.
+0

Хорошо. Я пошлю ваше первое предложение.Вы на самом деле советуете мне хранить все мои предварительно сгенерированные файлы на внешнем диске, подключать его к контроллеру или генератору нагрузки, а в моем сценарии ссылаться на этот внешний диск (в настройках параметров в моем скрипте), правильно? –

+0

Внешний диск будет еще медленнее, если вы не используете ESATA. Самый быстрый метод local - использовать внутренний SSD в качестве второго диска для каждого генератора нагрузки. Сохраните ваши предварительно созданные файлы на этом втором внутреннем жестком диске, а затем используйте файл параметров, чтобы передать информацию о имени файла и местоположении в сценарий. Я предполагаю, что вы будете внимательно следить за генераторами нагрузки во время теста за любой перекос в тесте, и у вас будет как минимум три генератора нагрузки (два для первичной нагрузки, один для управления). Вам, скорее всего, понадобятся дополнительные генераторы нагрузки –

+0

@JamesPulley, +1 Хороший совет относительно узких мест на жестких дисках. – Pacerier

1

Я думаю, что ваш скрипт почти там. Проблема, которую я вижу, заключается в том, что у вас нет уникального имени файла для создаваемого файла. Каждый из ваших 100 пользователей начнет с того же номера итерации.

Вы можете попробовать что-то вроде этого, создать новый параметр в списке параметров сценария под названием «Vuser» и присвоить ему тип "Vuser ID. Это будет заполняться как номер отдельного vuser, когда вы запустите его в контроллере. Это гарантирует, что ваши пользователи не будут наступать друг на друга при использовании файла. Добавьте это в имени файла, как это:

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

Это будет работать, пока все пользователи находятся в одной и той же группы в контроллере. Если вы используете это для нескольких групп, выполните одно и то же, добавив параметр «Имя группы» в имя файла.