headers
jason tilbury | 1 Aug 2011 12:16
Favicon

Handling loopbacks

Hi
I have an annoying situation where grinder is hitting a home page that actually is a javascript performing a loopback call to the server. The problem is that this seems to generate some url that can't of course be invoked by grinder, therefore grinder never sees the proper page, and hence misses out on session specific information. Anyone know of a general way of handling these situations so that I can see if I can manipulate it somehow?
 
cheers
J
------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey

_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 3 comments |
headers
Philip Aston | 1 Aug 2011 17:53
Picon
Gravatar

Re: Handling loopbacks

On 01/08/11 13:16, jason tilbury wrote:
> Hi
> I have an annoying situation where grinder is hitting a home page that 
> actually is a javascript performing a loopback call to the server. The 
> problem is that this seems to generate some url that can't of course 
> be invoked by grinder, therefore grinder never sees the proper page, 
> and hence misses out on session specific information. Anyone know of a 
> general way of handling these situations so that I can see if I can 
> manipulate it somehow?
> cheers
> J

Its theoretically possible to download and execute the javascript, but 
this would be quite a research project.

I'd say your best route would be first to capture and understand the URL 
generation behaviour of the javascript (either by inspecting the 
javascript code, or recording the behaviour with wireshark or the 
TCPProxy), then duplicate its function in your script.

- Phil

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
Permalink | Reply | 2 comments |
headers
David Amies | 2 Aug 2011 03:44
Picon
Picon
Favicon

Re: Handling loopbacks

I have a similar problem, I have an application written in Dojo That I need to test, I have tried with HTMLUnit (http://htmlunit.sourceforge.net/) and have had some success, it does spit out a lot of errors.
 
I am by no means a HTMLUnit, but it does seem to work with the grinder. I have got as far as opening the web page (with authentication) and getting the form elements, but have not successfully submitted the form (could be weirdness with my app?) The getting started guide (http://htmlunit.sourceforge.net/gettingStarted.html) has java examples that are not hard to convert to Jython.
If you try it I would be interested to hear how you go.
 
Dave.

>>> Philip Aston <philipa-O5WfVfzUwx8@public.gmane.org> 2/08/2011 1:53 am >>>
On 01/08/11 13:16, jason tilbury wrote:
> Hi
> I have an annoying situation where grinder is hitting a home page that
> actually is a javascript performing a loopback call to the server. The
> problem is that this seems to generate some url that can't of course
> be invoked by grinder, therefore grinder never sees the proper page,
> and hence misses out on session specific information. Anyone know of a
> general way of handling these situations so that I can see if I can
> manipulate it somehow?
> cheers
> J

Its theoretically possible to download and execute the javascript, but
this would be quite a research project.

I'd say your best route would be first to capture and understand the URL
generation behaviour of the javascript (either by inspecting the
javascript code, or recording the behaviour with wireshark or the
TCPProxy), then duplicate its function in your script.

- Phil

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
grinder-use mailing list
grinder-use-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/grinder-use

****************************************************
This message has passed through an insecure network.
Please direct all enquiries to the message author.
****************************************************

**************************************************** This message has passed through an insecure network. Please direct all enquiries to the message author. ****************************************************

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 0 comments |
headers
jason tilbury | 2 Aug 2011 11:34
Favicon

Re: Handling loopbacks

Thought that was what you would say ;)
 
I've managed to duplicate it...kind off anyway. The loopback script is it seems called frequently. Grinder does pick up the values generated (afrLoop) and it was these that end in (luckily - otherwise I would've been re-creating the javascript) what appears to be a server call to generate the random window ID used in the string (Oracles mechanism it appears for session management). BTW the technology under test is Oracle's content management suite. It is a pretty messy plethera of session variable and window id's in this technology that appear to make script creation particularly difficult. Before anyone else goes down this route, I'd advise overriding gets and posts to always pick up these variables in every response for changes into a self.afrLoop or self.afrWindowId, self.ctrlstate to name a few. Which does bring up an interesting question of whether or not you can get Grinder to use your own HTTP request/response variants when recording in the proxy?
 
Anyway moving on I also found that documentation states that if you record with

grinder.plugin.parameter.followRedirects True

 you might not see these redirections but for whatever reason this setting appears not to affect this result and it really just depends on me parsing the afrLoop variable and setting it in the next request. So one less red herring for people to ignore.
 
Thanks
On 1 August 2011 16:53, Philip Aston <philipa-O5WfVfzUwx8@public.gmane.org> wrote:
On 01/08/11 13:16, jason tilbury wrote:
Hi
I have an annoying situation where grinder is hitting a home page that actually is a javascript performing a loopback call to the server. The problem is that this seems to generate some url that can't of course be invoked by grinder, therefore grinder never sees the proper page, and hence misses out on session specific information. Anyone know of a general way of handling these situations so that I can see if I can manipulate it somehow?
cheers
J

Its theoretically possible to download and execute the javascript, but this would be quite a research project.

I'd say your best route would be first to capture and understand the URL generation behaviour of the javascript (either by inspecting the javascript code, or recording the behaviour with wireshark or the TCPProxy), then duplicate its function in your script.

- Phil

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 0 comments |
headers
Jean-Francois Poilpret | 3 Aug 2011 15:56
Picon

Problems with statistics of a Test wrapping other Tests

Hello list,
 
I have started using Gridner 3.4 for a few weeks now.
Recently I have decided to use Jython 2.5.2 in replacement to 2.2.1 that comes with Grinder 3.4.
After a couple of problems which I could finally solve (in particular, the patch attached here was useful: http://sourceforge.net/tracker/?func=detail&atid=118598&aid=2988755&group_id=18598), I am now stuck with one issue I can't find any workaround.
 
I have checked the list and the trackers to no avail.
 
I have a test script which I recorded with TCPProxy.
Here are some interesting excerpts (for those who are not used to Python scripts generated by TCPProxy):
 
...
request101 = HTTPRequestCheck(url=url0, headers=headers0)
request101 = Test(101, 'GET /').wrap(request101)

request102 = HTTPRequestCheck(url=url0, headers=headers1)
request102 = Test(102, 'GET jpetstore.css').wrap(request102)
...
class TestRunner:
  """A TestRunner instance is created for each worker thread."""
  # A method for each recorded page.
  def page1(self):
    """GET / (requests 101-103)."""
    result = request101.GET('/mybatis-jpetstore-6.0.1/')
    request102.GET('/mybatis-jpetstore-6.0.1/css/jpetstore.css')
    request103.GET('/favicon.ico')
    return result
...
  def __call__(self):
    """This method is called for every run performed by the worker thread."""
    self.page1()      # GET / (requests 101-103)
    ...
...
def instrumentMethod(test, method_name, c=TestRunner):
  """Instrument a method with the given Test."""
  unadorned = getattr(c, method_name)
  import new
  method = new.instancemethod(test.wrap(unadorned), None, c)
  setattr(c, method_name, method)
# Replace each method with an instrumented version.
# You can call the unadorned method using self.page1.__target__().
instrumentMethod(Test(100, 'Page 1'), 'page1')
...
 
Now when I run this script from the console (just one agent and one worker process), collected statistics show rows for test "100" (the test encapsulating "page1" method) and tests "101", "102"... (tests encapsulating each HTTP request).
 
The problem I have is that statistics data for test "100" are always 0, although they should aggregate statistics from each sub test.
 
Note that it worked well with Jython 2.2.1 and the "old" instrumentation.
 
I have checked a couple of things:
 
- data collected by the worker (data-*.txt file) have no trace of the test "100" at all (only the subtests).
- I have tried to replace "instrumentMethod" (generated by TCPProxy with the standard httpToJythonScript.xsl transformation) in order to directly transform the bytecode of the "TestRunner.page1" method, but this didn't changed anything
- inside the page1 method, I have added a call to grinder.forCurrentTest and this immediately threw an InvalidContextException
 
Now I am surprised to see this behavior for such a common scenario, and I wonder if I have something wrong somewhere in my setup.
Is there someone out there, using grinder 3.4, jython 2.5.2, and scripts generated by TCPProxy, that could confirm or refute this behavior regarding this fact?
Or someone who knows about this problem and has found a way to work around it?
 
If this matters, I am using Java version 1.6.0_23 64 bits on a Windows Vista 7 machine.
 
Any help would be greatly appreciated.
 
Cheers
 
Jean-François Poilpret
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 0 comments |
headers
Jean-Francois Poilpret | 3 Aug 2011 16:28
Picon

Problems with statistics of a Test wrapping other Tests (continued)

I have been performing some more tests by checking various combinations of Jython and Grinder instrumentation:
- Jython 2.5.2, DCR instrumentation: doesn't work (as described in my previous mail)
- Jython 2.2.1, old instrumentation: works fine (that was expected)
- Jython 2.2.1, DCR instrumentation: works fine (that was more surprising to me)
- Jython 2.5.1, DCR instrumentation: works fine too (that was a big surprise here!)
 
So the problem seems related to changes in Jython between 2.5.1 and 2.5.2
 
In the meantime, I think I will resume my experiments with Grinder 3.4 and Jython 2.5.1; actually I'm not sure I absolutely need Jython 2.5.2, although I generally prefer to sue the latest official release for any dependency.
 
Of course, I am still interested in any workaround ;-)
 
Cheers
 
Jean-François Poilpret
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 2 comments |
headers
Philip Aston | 3 Aug 2011 16:34
Picon
Gravatar

Re: Problems with statistics of a Test wrapping other Tests (continued)

Jython internals changed in 2.5.2 and broke a few things. The Grinder 
3.5 will have support for Jython 2.5.2. It also fixes some problems with 
DCR related to the instrumentation of Java methods, and a memory leak 
that occurs if you repeatedly instrument the same thing.

The fixes have been checked in. If you're adventurous, you can build The 
Grinder from the sourceforge svn repository. I'm hoping to release 3.5 
sometime this month.

- Phil

On 03/08/11 17:28, Jean-Francois Poilpret wrote:
> I have been performing some more tests by checking various 
> combinations of Jython and Grinder instrumentation:
> - Jython 2.5.2, DCR instrumentation: doesn't work (as described in my 
> previous mail)
> - Jython 2.2.1, old instrumentation: works fine (that was expected)
> - Jython 2.2.1, DCR instrumentation: works fine (that was more 
> surprising to me)
> - Jython 2.5.1, DCR instrumentation: works fine too (that was a big 
> surprise here!)
> So the problem seems related to changes in Jython between 2.5.1 and 2.5.2
> In the meantime, I think I will resume my experiments with Grinder 3.4 
> and Jython 2.5.1; actually I'm not sure I absolutely need Jython 
> 2.5.2, although I generally prefer to sue the latest official release 
> for any dependency.
> Of course, I am still interested in any workaround ;-)
> Cheers
> Jean-François Poilpret
>

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 1 comment |
headers
Jean-Francois Poilpret | 3 Aug 2011 22:00
Picon

Re: Problems with statistics of a Test wrapping other Tests (continued)

On 03-08-2011 16:34, Philip Aston wrote:
> Jython internals changed in 2.5.2 and broke a few things. The Grinder 
> 3.5 will have support for Jython 2.5.2. It also fixes some problems 
> with DCR related to the instrumentation of Java methods, and a memory 
> leak that occurs if you repeatedly instrument the same thing.
>
> The fixes have been checked in. If you're adventurous, you can build 
> The Grinder from the sourceforge svn repository. I'm hoping to release 
> 3.5 sometime this month.
>
> - Phil

Thanks Phil, that's what I thought (but I'm not a Jython expert, I 
didn't know Jython 2 weeks ago!). It's good to get this clarification.
Glad to know that Grinder 3.5 is soon to be expected.
I'm not sure I'll be adventurous enough to try the SVN trunk right away, 
I think I'll better wait :-)

Thanks again,

Jean-François

> On 03/08/11 17:28, Jean-Francois Poilpret wrote:
>> I have been performing some more tests by checking various 
>> combinations of Jython and Grinder instrumentation:
>> - Jython 2.5.2, DCR instrumentation: doesn't work (as described in my 
>> previous mail)
>> - Jython 2.2.1, old instrumentation: works fine (that was expected)
>> - Jython 2.2.1, DCR instrumentation: works fine (that was more 
>> surprising to me)
>> - Jython 2.5.1, DCR instrumentation: works fine too (that was a big 
>> surprise here!)
>> So the problem seems related to changes in Jython between 2.5.1 and 
>> 2.5.2
>> In the meantime, I think I will resume my experiments with Grinder 
>> 3.4 and Jython 2.5.1; actually I'm not sure I absolutely need Jython 
>> 2.5.2, although I generally prefer to sue the latest official release 
>> for any dependency.
>> Of course, I am still interested in any workaround ;-)
>> Cheers
>> Jean-François Poilpret
>>
>
>

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 0 comments |
headers
Saida Reddy | 5 Aug 2011 09:25
Picon

Using TCPProxy to capture the scripts with external HTTP proxy configured in my browser.

Hi,

We started using Grinder for as performance test tool.

We got stuck as we could not understand how to use the grinder
TCPProxy to capture the scripts in below scenario.

1. Our application runs in remote at some xx server with port yyyy.
2. We have HTTP proxy configuration with hostname aaa.bbb.ccc.dd and
port 1234 in browser to access the application.
3. If we need to capture the scripts, we need to configure the
localhost or IP as hostname and port of my local system in my browser
HTTP proxy configuration.If i configure this i will not be able access
the application.

Please help me with the solution. Please let me know if any further
details require.

Thanks,
Saida Reddy,

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
Permalink | Reply | 1 comment |
headers
jason tilbury | 5 Aug 2011 10:56
Favicon

Encoding/Decoding strings

Hi,
So I promised a certain someone that I would get around to detailing how I managed to decode gzip encoded responses from our web server.
 
The solution is quite simple (although there were niggles that I got around with a rather crude function that does the job - which ordinarily I wouldnt be using in real performance tests just for debugging so happy that it is crude) and out there in the web but perhaps not obvious.
 
Problem: when using the proxy Echo facitlity to debug my scripts I realised that I would not decode encoded responses from the server; subsequently it may as well not have existed as all I could see was gzip gobbledegook.
 
Therefore I needed to decode the response (a result from the HTTPRequest call such as result = request901.Get(....) ), and I wanted to do so without the need for a separate statement in every page/test. Well I never acheived the latter but managed the decoding enabling me to find all the session variables floating about in Oracles web communications.
 
#importantly the first step is to enable encoding by the following statement in your script, this ensures different types are decode into ascii/unicode strings that can be 'read'

connectionDefaults.useContentEncoding =

1

#However most likely due to certain characters that cant be encoding/decoded by typical means I then had to create specific functions to try encoding so for every page result I called the #following (apologies but indentation lost but I'm sure you can make sense of it). I put this in a helperclass for logging, parameterisation and other things and call it from a test with a filename and #response object (result). I use the try block to capture any encoding issues and to keep trying until it works - if anyone knows of a method of identifying whether a gzip compressed data stream #contains unicode/utf-8/ascii characters then I guess such a crude approach wouldnt be needed:

def

logResponse(self, filename, result):

if self.logResponseData:

filename = grinder.getFilenameFactory().createFilename(

"out"+filename, "-%d.txt" % grinder.runNumber)

file = open(filename,

'a+')

#input= new InputStream(result.getInputStream())

#MyURI.userInfo

try:

if (type(result) is not str):

MyURI = result.getEffectiveURI()

file.write(

'=============URI information===============')

#print >> file, 'User Info:'+ MyURI.getUserInfo().encode('ascii')

file.write(

'Path&Query:'+ MyURI.getPathAndQuery().encode('ascii'))

file.write(

'URI string:'+ MyURI.toString().encode('ascii'))

file.write(

'=============URI information End===============')

#print >> file, result.getHeader()

try:

file.write(result.getText())

#.encode('ascii'))

except:

file.write(result.getText().encode(

'utf-8','ignore'))

finally:

file.write(result.getText().encode(

'ascii','ignore'))

#file.write('########################original uri#################')

#file.write(result.getOriginalURI())

#file.write('########################end uri######################')

file.write(result.toString().encode(

'ascii'))

else:

file.write(result)

except Exception:

print "Write failed:%s"%Exception.message

file.close()

return 0

file.close()

return 1
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
grinder-use mailing list
grinder-use@...
https://lists.sourceforge.net/lists/listinfo/grinder-use
Permalink | Reply | 1 comment |

Gmane