JMeter log parsing issue

[GoogleCodeExporter]

We may need a new approach to determine what a page is.

I'm getting lots of pages that look like :

/home.do?JSESSIONID=120938712897
/home.do?JSESSIONID=23423423144

etc etc. 

Clearly these are actually the *same* page in different sessions, but is it
really safe tojust truncate all the parameters. For example I may have an
application that does this (I'd need to be shot but *someone* will have
done this).

/getTheData.do?query=shortDataSummary
/getTheData.do?query=hugelyExpensiveDataRequestScanningAllTables

In this instance you probably want to track these as different pages as
they are fundamentally doing something different.

So does this mean we need to issue a set of params we will remove from the
request in determining the page name?

Original issue reported on code.google.com by paul.goulbourn on 29 Sep 2006 at 8:40

[GoogleCodeExporter]

I think a list of parameter names to remove would be a reasonable solution. 

One comment: we need to ensure that removing a parameter does clean up the URL 
in a way to make the page 
the same as one without the parameter. Ok, that was as clear as mud.  Let me 
try that via an example:

If you "remove JSESSIONID" from "/home.do?JSESSIONID=120938712897" do you get 
"/home.do?" or "/home.do".   
I think you should get the later so that the page is the same as a request to 
"/home.do" elsewhere.

Original comment by dalla...@gmail.com on 29 Sep 2006 at 9:49

[GoogleCodeExporter]

Turns out that the xml  page encoder actually modifies the URI already. So for
example the above view is actually not a ? but a ; as param seperators.

We also need to deal with the page names, as these are being used to produce the
images and labels we have to encode in some way (think / chars :'s etc etc).

Right now I have removed *all* params and used URLEncoder to "sanitize" the URI.

Clearly this is an area we need to revisit, as this solution is less than ideal.

Original comment by paul.goulbourn on 30 Sep 2006 at 11:57

[GoogleCodeExporter]

Have written in the example docs that providing a proper name for the tasks is
reccommended rather than leaving the defaults generated by the proxy tool.

In reality if you name a task then all the above issues seem to dissapear, in 
that
naming a task "Search - long search" and "Search - short search" are already
disambiguated. In addition named tasks do not seem to suffer the JSessionId 
issues
described above.

In summary - encourage users to name tasks, and leave the above solution in 
place for
now to stop unnamed tasks causing trouble on chart generation.

Original comment by paul.goulbourn on 30 Sep 2006 at 8:47

[GoogleCodeExporter]

Original comment by dalla...@gmail.com on 10 Oct 2006 at 9:15

• Changed state: Fixed