|
Vadim @StresStimulus Administrator Posts: 583
5/13/2011
|
***Completed***
Need the ability to display and modify think time for every primary request individually. This feature request was mentioned in this post.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
5/19/2011
|
An option to modify Think time was added in the second May-11 Pro release.
The user can view and change recorded think times In Test Case area -> Page Settings. Accuracy of replaying recorded think time was improved as well. Specifically, replaying long think time on AJAX pages should be more precise.
Note: For better accuracy, it is recommended to pause for at least 5 seconds between mouse clicks when recording test case.
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
5/20/2011
|
Thank you for the feature. From first look, it looks like it's only for primary page requests? Can you clarify how the feature will work?
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
5/22/2011
|
Huong,
When user navigates through a web application, primary requests are triggered by the user’s actions. Think time is a delay that user needs before requesting a subsequent page. In contrast, dependent requests, which are mainly page resources, are triggered when a browser is parsing a response to the primary request. They are being issued automatically as fast as the system performance allows.
When you create a test case, StresStimulus recognizes primary requests and determines the think time that took place during recording. In the new StresStimulus version you can view and change recorded think times.
When test case is being replayed, StresStimulus injects a wait time delay prior to issuing the subsequent web page primary request. Once the primary response is received, StresStimulus replays dependent requests (resources) as fast as possible while complying with simulated performance constrains. The performance constrains are mimicked by imposing limitations of selected browser and network type. The figure below illustrates how StresStimulus pours requests in a typical load test with multiple virtual users, replaying multiple iterations of a test case, comprising of multiple pages.
Does it make sense?
Cheers,
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
5/24/2011
|
Hi Vadim, it makes a lot of sense, thank you. However, I won't be using this feature just yet because with the current recordings, I will need to change a lot of primary requests. I'll update you regarding the functionality when it's used for the next project. Also, I can't see the picture you've posted.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
5/24/2011
|
Huong,
Thanks for mentioning the issue with the picture. I checked in IE, FF and Chrome and it seems to show-up OK on my end. I uploaded the picture *** here *** . Try if this will work.
I look forward to your update to learn the need to change the primary requests.
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
5/25/2011
|
Hi Vadim, I can see the picture now, thank you, and it makes sense. I'm not going to be done with the current project anytime soon, so I'll update in a few months or so, hopefully.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
5/25/2011
|
Good luck with your project, Huong.
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
5/25/2011
|
Thank you! My sanity is saved by using StresStimulus! Hope to get this done soon.
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
6/14/2011
|
Hi Vadim,
I really need to use your primary/dependent request functionality. However, I need the primary request to be correct. For the application I'm testing, these usually include calls to .aspx pages. I see that sometimes, the application thinks that a gif request is a primary request, which is not the case. How does your application detect primary request? What are the criterias? If I know the criteria, maybe I can fix my recorded requests so that the application will detect the primary requests I want better. Hope to see your reply soon.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/14/2011
|
Hi Huong,
In v0.9 we reworked the heuristic algorithm of primary request recognition, and it substantially improved the accuracy. The alpha that we test internally, unlike before, determines primary requests flawlessly in our test cases.
Would you be interested to test the alpha before the "official” beta release? If yes, I can forward it to you today.
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
6/14/2011
|
Yes, please.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/14/2011
|
The alpha is available for download from http://www.stresstimulus.com/genericerror.aspx
Release notes will be out in a few days. I hope that the most of the new features are self-explanatory with the aid of Help boxes. Please let me know if any questions or issues will come-up.
Thanks,
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
6/15/2011
|
Hi Vadim,
Thank you! The run time is much better, and closer to my expected value.
From initial usage, these are my feedbacks:
1. There are some negative timeout in the page settings. Is this suppose to happen? I can send you the script if you like.
2. Not all ASPX pages are suppose to be primary (very minor issue) - for example, we have JavascriptString.aspx that are not suppose to be primary requests.
3. Some web service calls are supposed to be primary requests to us, because it's triggered by user action. For example, when a user clicks save metadata, we make a web service call to RequestUpdateMetadata, and this wasn't detected as a primary request.
Am I understanding primary/dependent requests correctly?
I also am running into some iteration problems, I will look into it tomorrow, and will let you know.
Thank you so much for this release!
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/15/2011
|
Huong,
Thanks for testing. It looks like you found a few issues.
1. There are some negative timeout in the page settings. Is this suppose to happen? I can send you the script if you like.
Timeout should not be negative. The script will definetely help to troubleshoot.
Am I understanding primary/dependent requests correctly?
Yes, you do understand the the definition of primary/dependent requests correctly.
Because primary/depended request recognition errors are possible, StresStimulus has an option to manually override primary/depended marking in StresStimulus context menu after right-mouse-click on selected sessions in Fiddler grid. However such recognition errors should be infrequent. If you can forward the test case (the saz file) with recognition errors that you described in (2) and (3), I would be happy to troubleshoot. I would not need to run it, just review the request sequence and the headers.
I also am running into some iteration problems..
I am looking forward to your comments on iterations
Thank you,
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
6/21/2011
|
Hi Vadim,
"Because primary/depended request recognition errors are possible, StresStimulus has an option to manually override primary/depended marking in StresStimulus context menu after right-mouse-click on selected sessions in Fiddler grid."
Is there a way to programmatically do this right now? For example, if I set the request color to purple or something, does SS recognize as a primary request? What are the criteria for SS to detect this?
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/21/2011
|
Huong,
First let me give you an update on testing your saz filed that you forwarded last week. Sorry for the delay with the response.
In v0.9 we further improved the primary request recognition algorithm. Now I no longer see any .GIF files or JavascriptString.aspx to be primary. There are also no negative think times. I noticed that your CustomRules.js sometimes modifies the request, so I tested with the default one.
As far as RequestUpdateMetadata – it looks like it is an AJAX request. SS does not support AJAX as primary request. So if you need them as primary you would need to change them manually.
Can you change it programmatically? The short answer is, no. This change should be made when you set the test case and before you load test started. The manual change has to be made once and then it will be stores in the SS Test and used in every test iteration automatically. I wonder, what are you trying to accomplish by programmatic and not manual setting RequestUpdateMetadata (or similar) as primary?
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
6/21/2011
|
The reason is that I have 6 different test cases and I'm running these on different machines. They have some actions that are similar and I know which one I should set as primary, depending on certain criteria in the request's body and headers. To be able to programmatically set it will lessen the manual work I have to do, which will reduce probability of user error. This will then reduce the number of times I have to run tests. In addition, it's easier for version checking, since I commit the custom code into SVN. Thus, when comparing load test results, I will be able to exactly track changes and determine cause and effect relationships. As you've noticed, I have to change a lot of traffic from my custom code script, therefore, having all changes in one place would be most efficient for me.
One more note: my test batch file I always replace the saz used by SS with a clean one, so that changes in my custom code will always use the clean initial recording, then it will modify the template requests upon loading according to the custom code. Therefore, it's never using the saved SS saz.
|
|
|
0
link
|
|
Vadim @StresStimulus Administrator Posts: 583
6/22/2011
|
Huong,
While I do not have a full solution for your task, I wanted to send you pieces of the puzzle, so you can check whether what you need can be done.
When user clicks “Set Test Case”, StresStimulus marks sessions as primary or dependent by setting 2 flags in the Fiddler sessions. Below I put together two sample functions in C# that set or update these flags:
public void MarkSessionAsPrimary(Session s)
{
s.oFlags["x-ws-base"] = "";
s.oFlags["x-ws-force"] = "";
}
public void MarkSessionAsDependent(Session s)
{
s.oFlags["x-ws-force"] = "";
if (s.oFlags.ContainsKey("x-ws-base"))
{
s.oFlags.Remove("x-ws-base");
}
}
When save sessions in .saz file, these flags will be saved as well. If you mark sessions before SS sets the test case, while SS may set the flags in other sessions, it should not change your flags. You also can mark sessions after SS sets test case, but by design SS completes marking sessions before the session replay starts. I am not sure though where to appropriately to invoke this code.
Let me know if this was helpful.
-Vadim
|
|
|
0
link
|
|
Huong Nguyen Posts: 69
6/22/2011
|
This is perfect, thank you!
|
|
|
0
link
|