HomeSUPPORT QUESTIONS

Need help with StresStimulus? Start here.

What determines which sessions are marked in red as errors? Messages in this topic - RSS

Tessa Adair
Tessa Adair
Posts: 5


7/29/2014
Tessa Adair
Tessa Adair
Posts: 5
During a test, I am seeing many sessions show up in the sessions list that all have the same HTTP error code and otherwise seem the same. However, only a scattered handful of these sessions are marked in red and included in the error count. What are the default settings that determine which sessions show up in red as errors? 
0 link
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583


7/30/2014
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583
Hello Tessa,
 If I understood correctly, you made two observations:

  1. During the test run, a number of sessions in the session grid appear with the same error, but only some of them are marked in red.

  2. Only some of these errors are included in the StresStimulus error count.


 
Please note the following:

  1. On your 1st observation:  By design, Fiddler marks all sessions with response code in the 400 and 500 ranges in red. Are you sure that HTTP errors in the Fiddler grid  are not highlighted in red? I suggest to double check that all those sessions are in fact the HTTP errors. To do so, sort Fiddler grid by the response code to verify that all those sessions have the same error.


 

  1. On the 2nd observation:  StresStimulus has two stage error checking.


        a. On the Verify stage, StresStimulus registers 3 types of issues, as described here               http://support.stresstimulus.com/display/doc37/Verifying+the+Test+Case
 

  • Errors - Sessions with errors related to the test configuration. Configuration-related errors indicate that some test configuration should be adjusted. Most often such errors can be fixed by adding missing parameters. Try to find and create such parameters using Parameter Finder.

  • Warnings - Sessions with issues that may or may not be related to the test configuration. Try using Parameter Finder to eliminate or reduce number of warnings. After that, inspect remaining warnings to make sure that they are not caused by missing settings in the test configuration.

  • Notifications -  Sessions with issues unrelated to the test configuration. Notifications can be rectified by refining your application. For example, broken links of missing images will causes 404 HTTP errors. Such errors can be fixed by making adjustments in the tested application.


 

  1. On the test run stage, only the errors that are caused by the load are counted.  So if a 404 error was registered on the verify stage, it will be not be counted as a load test error.


 
If you cannot sort-out errors in you test, feel free to contact support so we can set up a support session.
0 link
Tessa Adair
Tessa Adair
Posts: 5


8/12/2014
Tessa Adair
Tessa Adair
Posts: 5
Regarding my first observation, here is what I see when I sort by response code. 



My test case only has that one page, and as far as I can tell they are all the same except for the fact that some are bolded red, some are bolded grey, and some are unbolded yellowish. Any idea what the differences might be between these?
0 link
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583


8/13/2014
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583
Hello Tessa,
This error indicates that your application requires server authentication (like NTML or Kerberos).  Go to the Authentication tab in the Workflow tree and add at least one set of credentials as described here. This will fix all errors it once.
0 link
Tessa Adair
Tessa Adair
Posts: 5


8/18/2014
Tessa Adair
Tessa Adair
Posts: 5
Hi,
Yep, I am already using authentication (without which there are way more 401 errors), but the ones in the screenshot are still sticking around. Some 401 errors are recorded with the test case, so I expect to see some, but not all of these. I am now trying to understand which of these 401s are expected and which are not. This is why I want to know what the color-coding means. 
0 link
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583


8/19/2014
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583
Hi Tessa,
Session color is determined by Fiddler depending on  the status code,  mime type and  traffic type as described here. For example,  errors are red; authentication demands are yellow; CONNECTs are gray. 
From authentication standpoint, StresStimulus emulates real browser behavior. It does not record sessions with 401 responses.  Instead StresStimulus issues authentication requests when server responds with 401. The number of such requests is determined dynamically.  So 401 received during the test run are not caused by  recorded 401  sessions.
 Does this make sense?
 
0 link
Tessa Adair
Tessa Adair
Posts: 5


8/20/2014
Tessa Adair
Tessa Adair
Posts: 5
Yes, makes sense.

Can you provide any more details about this:
The number of such requests is determined dynamically.

0 link
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583


8/20/2014
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583
Tessa,
As I said before, StresStimulus issues authentication requests when the server responds with 401. For example, if the application sends two 401 responses before authenticating a session, then StresStimulus will emulate real browser behavior by sending three authentication requests per session.
The number of round-trips to authenticate a client depends on the authentication method used by your application.  For example, Kerberos uses one round trip. NTLM has a "challenge" phase that adds a second round trip.
 Hope this will help.
0 link
Tessa Adair
Tessa Adair
Posts: 5


8/22/2014
Tessa Adair
Tessa Adair
Posts: 5
Okay, so for an example test case, my application sends two 401 responses before authenticating a session. When I run a test with 1500 total requests, I see 1000 sessions in Fiddler that have a 401 response code, and the other 500 are all 200s. From what I understand, this is expected. 
However, StresStimulus says there were 70 HTTP errors. Yet there were no errors, warnings, or notifications in the verify stage. So does this mean that StresStimulus is deciding that 70 of the 401 responses are "caused by the load"? 
Only 21 of the sessions appear red in the Fiddler grid. 
0 link
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583


8/23/2014
Vadim @StresStimulus
Vadim @StresStimulus
Administrator
Posts: 583
Tessa,
Here is the logic/process I suggest you to follow for analyzing your test result:

  1. Because " .. there were no errors, warnings, or notifications in the verify stage" your test configuration is correct. You should expect no test run errors caused by incorrect script.

  2. Because "StresStimulus says there were 70 HTTP errors" it is likely that all of these errors were caused by the load.

  3. Retrieve the 70 error sessions from the test log as described here http://support.stresstimulus.com/display/doc37/Querying+the+Test+Log    On the test log query window, make sure that all fields are cleared and check the Error box. The exactly 70 sessions will appear in the session grid. Analyzing these 70 sessions to determine if they are caused by 401 responses or different reasons. Disregard the 1000 sessions with 401 which you saw before, because 1000 is a (configurable) limit of sessions displayed in the session grid when test runs in debug mode. 

  4. To analyze every error, double-click the session. The content of the request and response will be displayed in the appeared session inspector. The response body may display a server error message or give you a clue on what went wrong. 


 
Does this make sense?
-Vadim
0 link






Copyright © 2017 Stimulus Technology