Also note that parsing for frame URLs will most likely not resolve your problem, since most frame-based sites use tons of JavaScript to trigger multiple loads on a single click -- and there's no way JMeter will run that javascript (well, it could, but I guess we don't want to).
Another caveat: while you can easily configure the proxy to record/not record images, it's not that easy to have it avoid recording sub-pages -- actually, I don't believe this can be done. So you would still need to go through your script deleting those sub-page samplers...
In short: you'll be better off adding one timer to each 'main' sampler. (Which doesn't mean we don't want to implement the frame URL parsing).
-- Salut,
Jordi.
En/na [EMAIL PROTECTED] ha escrit:
Don't try it - I already have...and, to be fair, it worked.
BUT it meant I had to have the negative timer attached *to each* group of clicks (in my case, an individual Recording Controller for each mouse click) with the positive timer set at the higher level. The Test Plan soon became unwieldy with a Recording Controller representing each mouse click and negative timers overriding positive ones. Yuck.
I guess my issue is: do you want to record all three resultant URLs - and treat them as individual URLs (when they really are not) or should we just record the first one sent by the mouse click...and have JMeter intelligently deal with the result (just as you already do with images)?
Cheers
Paul
from: Jordi Salvat i Alabart <[EMAIL PROTECTED]> date: Tue, 25 Nov 2003 22:48:26 to: [EMAIL PROTECTED] subject: Re: Parser refactoring; should Jmeter fetch more than images/applets?
Thought about including FRAMEs and IFRAMEs in the result sets when doing the parser thing. That's trivial. Having the sampler recursively parse text/html results should be doable too. Ideally, this would require passing the information on the expected MIME type of the resources, but I'd say we can live without that...
What's the proble, with puting your timer inside the login.jsp sampler?
We could also think about some timer-cancellation component that would cancel the effect of any timers higher on the tree. But it's probably not worth the hassle. (It may be that you can actually obtain this by adding a -999999 constant timer... need to try).
-- Salut,
Jordi.
En/na [EMAIL PROTECTED] ha escrit:
Might I suggest that JMeter must also retrieve parse the result and retrieve Framesets automatically otherwise Timers will become increasingly unusable!
Take as an example a login.jsp URL that upon successful authentication returns the following (Home) page:
<frameset rows=52,* framespacing=0 frameborder=no border=0>
<frame name="witopbar" src="topBar.htm" marginwidth=0 marginheight=0 scrolling=no frameborder=0 NORESIZE> <frameset cols=80,* framespacing=0 frameborder=no border=0> <frame name="winavigationbar" src="navigationBar.jsp?WflowType=W" marginwidth=0 marginheight=0 scrolling=AUTO frameborder=0 target="rbottom" noresize > <frame name="rbottom" src="welcomeDefault.jsp"> </frameset> </frameset>
The browser interprets this and immediately sends THREE requests back to the server a) toBar.htm b) navigationBar.jsp c) welcomeDefault.jsp
So I end up with several URLs sampled by the <a href=b) make the <a href=Hearmon
------------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
