On 30/10/2007, Richard Hubbell <[EMAIL PROTECTED]> wrote: > --- sebb <[EMAIL PROTECTED]> wrote: > > On 30/10/2007, Richard Hubbell > > > > The Link Parser only produces useful output when > > it > > > > finds a link. If > > > > there is no link in the previous page, it will > > not > > > > update the current > > > > sampler. > > > > > > So if the regex is "one or more of something" than > > I > > > should never see it trying to do a GET > > http://.+/.+ > > > right? Or is something else at play here? > > > > > > > I don't understand what you are saying here. > > > > The Link Parser looks for links in the previous > > page, and tries to > > match them against the current sampler. > > You don't understand me and I don't understand Jmeter. > We're not getting anywhere.
"This modifier parses HTML response from the server and extracts links and forms. A URL test sample that passes through this modifier will be examined to see if it "matches" any of the links or forms extracted from the immediately previous response. It would then replace the values in the URL test sample with appropriate values from the matching link or form. Perl-type regular expressions are used to find matches. Matches are performed using protocol, host, path and parameter names. The target sampler cannot contain parameters that are not in the response links." If the sampler does not match any links (or there are no links) then the sampler will not be modified. > I still don't understand how the sampler could > do a GET http://.+/.+ If the sampler has not been modified, then it will do whatever you have told it to do. > That's literally what the server sees Jmeter doing. Of course. > Can you explain the flow of that in pseudo-code? > (using the link parser and a sampler) See above. > > > > > > > > > > > In regexdom it's a bad idea to use .*, it > > should > > > > be > > > > > used sparingly. > > > > > > > > It's only a problem where there is trailing > > context, > > > > as that causes > > > > back-tracking. > > > > > > > > .* with nothing after it is OK, but .*?; would > > be > > > > better as [^;]*; > > > > > > > > Same for .+. > > > > > > > > > > > > > > > > > > > > > Another issue is using 1000 threads with 1 > > loop > > > > just > > > > > > does not make sense. > > > > > > > > > > Does not make sense in general or just to you? > > It > > > > > makes sense to me. I would have used 10,000 > > but > > > > the > > > > > jvm is a bit hungry with memory. There may be > > > > some > > > > > tuning still needed. Stack size, etc. > > > > > > > > > > Imagine that each loop does more than one > > thing. > > > > > > > > > > > > > But given the ramp-up time, the threads don't > > run in > > > > parallel. Even > > > > with a very short ramp-up time it's likely that > > the > > > > earlier threads > > > > will have finished before the later ones start. > > > > > > > > Better to run a few threads (or one thread) > > multiple > > > > times. > > > > > > Better for what? Better's loaded with context. > > > > Fewer resources. > > Shouldn't be a limiting factor in testing, if it is, > it will be hard to push a system hard enough to see > how it behaves at high transaction rate. Indeed, which is why it is important to use the test tool efficiently. > > > > > Not every test is a onesy-twosy affair. Sometimes > > > people want 10,000 threads in parallel hammering a > > > website or service. It happens that way. Better > > to > > > find out sooner if it's going to fall over. > > > > Indeed, but 10,000 threads with 1 loop will have at > > most a few threads > > running in parallel at any one time. > > That depends on the test though. Of course. But more threads still require more resources. > > > > It is also not an efficient use of JMeter, as the > > thread startup costs > > are likely to be a significant proportion of the > > total. > > See above. Make sure to have plenty of RAM. And CPU. > > > > > > > > > > A single thread can represent multiple users. > > > > > > Yes and many threads can represent a single user. > > > > I disagree; multiple parallel threads inherently > > represent multiple users. > > It's not a matter of disagreeing, it's more about what > you want to test. What if a page has 50 db > connections via ajax or something. One user loads one > page and that cause 50 transactions plus css, plus > imgs, plus js, plus, etc., etc. > > > > > > E.g. a human user with a single keyboard can only > > provide input to a > > single browser at a time. > > Not if they're running Jmeter. (^: > See above. But that is not a real-world user. > > > > > Though of course if one thread finishes before the > > next one begins > > they could represent one user, but then why bother > > with multiple > > threads? > > Well maybe you want to do that to test something you > haven't imagined or encountered. Of course you are free to use JMeter as you see fit. > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > 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]
