| || |
log message on error memory usage
I have a situation where I want to capture a fairly large HTTP response, about 250K bytes, when a text verification fails (screen snapshot is not useful as this request returns a response that is evaluated by browser site JS and then an appropriate page is rendered to the user).
But I find that the Runtime Settings->Log->Send message when an error occurs->Advance->Size in KB is limited to 100K. So I have these questions:
1. Is there anyway "under the covers" to extend this size beyond 100K?
2. Does each vUser always consume this buffer size during runtime or is it dynamically allocated, used when an error needs to be logged, and then de-allocated? (can't find this in LR docs).
3. If I correlate and snag an HTTP response and log it with an lr_error_message() will the log entry size be truncated to the Runtime Settings->Log->Send message when an error occurs->Advance->Size in KB setting size? (again, I can't find this in LR docs).
4. Lastly this single HTTP request results in a lot of responses, redirections, etc. along with EXTARES requests. I would like to capture all these responses as a blob of text (to give to the developers) and am not sure how I correlate to do that--in other words I want to capture what I see in vuGen when I have full logging turned on for that request's response. Can anyone suggest how I can do this explicitly?
-Much Thanks, Terry Horwath
You have a question which is both simultaneously interesting and ugly Terry! And that is not a bad thing
1. I took a look at VUGEN and found the confirmation on the error buffer that you note. I took a marker value of 99 and saved the script. I then opened up the default.cfg file and found the entry which corresponds to the buffer size, "AutoLogBufferSize=99" in my case. I changed the value to 999 and reopened the script. This value showed in the advanced settings for the log. The script compiled and ran, but this would likely be an untested case if you ran into issues with support. The validation appears to be when you change the value to not allow for more than 100, but if the value is set to another value manually then the script appears to run. I did not take time to benchmark mdrv size in both cases to see if it made a difference.
2. I suspect that this is per user. The reason why is that the page contents need to be held until the error condition can be determined, such as a missing Web_reg_find() or missing web_reg_save_param[_ex]() which takes until the end of the defined response set. You could trim this by going to URL with explicit calls for each resource, which would trim the buffer to just the component you are evaluating instead of all the page components. I'm note sure I would do this for the entire script, but I might replace the one page in question with a breakout of all of the requests.
3. Unknown. I would have to test for this. Should be easy to test for if you have large pages. Just set the amount to be 2K and see if the amount is truncated. What I don't know is if this value is set to 1 if that is the same as unlimited (special case). Also untested but should be easy enough to test for truncation.
4. What is dumped reflects the values for logging which follows. So you could certainly set the extended log attributes for the information you want and need. Pages and all page components can be quite large these days. I read a stat recently that the average page is in excess of 1MB in size for all components. Frightening from a network dependency standpoint. This gets back to my reference above on breaking out the page components for the one page using explicit URLS for each resource rather than HTML mode or HTML mode with explicit URLS. You will have more control over what you dump and report because then based upon error condition you could turn up the log levels for the resources and then turn down the log levels when the end of the page set is reached. This won't help you if the page comes back in a completely different defined state without the expected resource components, but you will see the dramatic page definition in the first captured flow.
Hopefully this helps,
Replace ineffective offshore contracts, LoadRunnerByTheHour
. Starting @ $19.95/hr USD.
Put us to the test, skilled expertise is less expensive than you might imagine.
Twitter: @LoadRunnerBTH @PerfBytes
This is most helpful to me. Now I have to go away and experiment. In particular, the default.cfg file hack, which might get me over this immediate crunch to deliver "error isolation" information quickly. I am finding more and more clients unwilling or unable to debug on their servers with us. And that is a (time/money) problem for us because LR is a great tool for error "detection" but not so much for error "isolation".
-Much Thanks! Terry
Well here is some feedback on my results:
1. I needed to do the "AutoLogBufferSize=xxx" hack in the scenario file, rather than in the vuGen script. So open the *.lrs with any text editor and search for and edit the "AutoLogBufferSize=" statement, which is part of the command line invocation, as in:
Config=[CommandArguments]\r\ndebugLevel="1"\r\n~debugLevel=""\r\n ... nLogOptions=LogExtended\r\nAutoLogBufferSize="250" ...
2. As noted above I tell LR to capture 250K buffers of text (and I also have only log on error enabled).
3. When I ran the scenario and the two errors I was after occurred LR captured more than 100K bytes of text per log entry. I am uncertain if LR is counting the text it places on each line as part of the byte count, as in:
Start auto log messages stack - Iteration 2. [MsgId: MMSG-10545]
The raw log text for each of two different types of errors was 170K and 185K respectively. Not sure why this byte count is not 250K as requested, but then again we are setting the buffer size to 250K "under the covers" so I guess I should be surprised. When I deleted most of the LR preamble statements from most lines I then get 130K and 150K respectively of pure HTTP response text. (So your mileage may vary with this hack...).
Luckily for me the error response payload is substantially smaller than the non-error response, and I was able to trap the problem.
Last edited by Terry Horwath; 09-26-2015 at 06:26 AM.