Hi, I agree with LJ here, if you are testing the midtier backchannel API a handful of different users will help you avoid any caching problem, if you are testing the API then it becomes less important.
One thing to be aware of is session handling and generalising unique IDs for setEntryList calls - historically HP / Mercury Load Runner has not been good at this - it maybe worth considering ARS specific tools such as Silk Performer or Scapatech (I know these guys are on the list) With a specific tool the extremely long native URLS are converted into more manageable XML representations. Good luck and let me know if you need any help! Regards, Dom From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, Lj Sent: 06 August 2013 14:14 To: arslist@ARSLIST.ORG Subject: Re: LoadTesting ITSM 764 ** from a caching perspective it may make a difference. Having 50 of the same user doing the same action is easily cashed by both the DB and the Web server. I would think two or three users with different permissions, performing different actions simultaneously (multiplied by many of course) would be a bit better from a load perspective. On Tue, Aug 6, 2013 at 6:34 AM, Frank Caruso <caruso.fr...@gmail.com<mailto:caruso.fr...@gmail.com>> wrote: We are load testing ITSM 764 using a tool from HP. The script is working well and simulates a user logging in, moving to the new incident form, filling out a ticket and clicking Save. We have set up 50 concurrent sessions and had it running for 10 minutes. For ease of set we have been using the same Remedy login creating a new Web session for each. Does it matter that we use the same login and would it make a performance difference if we used a unique login for each session? Thank you Frank Caruso _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"