Ah yes, you did indeed :) I've just seen that, thanks. So that means JMeter isn't preserving the session and is being sent back to the login, but still, why does it take so long for it to (not) follow the redirect? We make quite liberal use of redirects, and if JMeter can't follow them easily then it's rendered useless for performance testing our site :-/
Ok, I can understand the waiting for the time-out when Following Redirects is disabled, but with redirects *enabled*, surely it should go straight to the LoginServlet as it had been redirected to, without taking 15 seconds AND reporting a gobbledegook response time of around 1060694099970!? Thanks again, Duncan Frostick [EMAIL PROTECTED] wrote: > On 12 Aug 2003 at 11:19, Duncan Frostick wrote: > > [snip] > > If we look at the dumps there something very obvious thats wrong. When doing a GET > > on > > the 'Plan Page' (/planrecord/servlets/PlanServlet), Mozilla Firebird and all other > > broswers (and Raw communication over telnet) receives a '200 OK' response. JMeter > > on > > the other hand, despite doing an identical navigation, gets a 302 redirect with the > > location the same as the request (/planrecord/servlets/PlanServlet). > > I don't know if we're looking at different things, but I saw JMeter being redirected > to > /planrecord/servlets/LoginServlet, not PlanServlet. > > -Mike > > > > > To see this, look at packets 71-72 on the FirebirdNav.dump, and then compare it to > > 29-30 and 30-31 in JMeter-NoFollowRedirects.dump and > > JMeter-WithFollowRedirects.dump > > respectively. > > > > Why does JMeter get a 302 when all other browsers get a 200 OK? > > > > This is the heart of the problem because upon receiving the 302, with redirect > > following enabled or not, JMeter just sits and waits for the Timeout to arrive (15 > > seconds as it says in the header) without GETting any more data. Why is this? Am I > > missing a very obvious client/server setting that will stop JMeter from doing this? > > > > > > Any help much appreciated guys, > > > > Cheers, > > > > Duncan Frostick > > > > > > > > Jordi Salvat i Alabart wrote: > > > > > Hi Duncan. > > > > > > I tried to reproduce this locally, but the script performs flawlessly. > > > Since I don't have access to your server, I just created "fake" > > > responses (mimicking yours where I know the details) on my server. > > > Didn't help: I still get very low measurements (2 ms for the "Plan Page" > > > 302 response). > > > > > > Questions: > > > - Does the 302 response for the "Plan Page" request have a large body? > > > - Which O.S. & JDK version are you using? > > > - Could you get a tcpdump or ethereal log of the JMeter/server interaction? > > > > > > -- > > > Salut, > > > > > > Jordi. > > > > > > Duncan Frostick wrote: > > > > Just tried with 1.9, same problem. > > > > > > > > Seems to have something to do with redirects (HTTP code 302)... but I'm not > > > > sure. > > > > > > > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > > > >>Never seen anything like that - what does your test look like, exactly? Which > > > >>version of JMeter are you using? Did you try recording using JMeter's proxy, > > > >>and if so, did you get the same delay there? > > > >> > > > >>-Mike > > > >> > > > >>On 7 Aug 2003 at 12:20, Duncan Frostick wrote: > > > >> > > > >> > > > >>>Hi, > > > >>> > > > >>>I need to stress test a server running Java Servlets, JMeter should be > > > >>>ideal. With these Servlets, there is a very standard login/out system in > > > >>>place for users of the system. For example, to get to any of your > > > >>>records on the server, you must Log in though LoginServlet from which > > > >>>you can then go to the other servlets. Very standard stuff. > > > >>> > > > >>>However, with JMeter, with even the most simple test plan, a login > > > >>>consistently takes over 15 seconds. The login is done exactly as the > > > >>>browser does it (verified using BadBoy to capture everythng and then > > > >>>exported to JMeter), but JMeter sits and waits after posting the login > > > >>>information for over 15 seconds - and it just does not make any sense. I > > > >>>haev also tried without the BadBoy generated file, it threw up exactly > > > >>>the same problem. > > > >>> > > > >>>It's not the servers at fault. It's running Apache 2 on Solaris. This 15 > > > >>>second delay isn't replicable in any browser. Additionally, I captured > > > >>>the packets JMeter was sending and resent them raw over telnet exactly, > > > >>>but there was no 15 second delay. It seems to be something totally > > > >>>internal to JMeter. > > > >>> > > > >>>How can I address this? JMeter is my only option for stress testing, but > > > >>>this 15 second delay on *every* login is rendering it useless. Any > > > >>>ideas? > > > >>> > > > >>>Thanks for you time, > > > >>> > > > >>>Duncan Frostick > > > >>> > > > >>> > > > >>>--------------------------------------------------------------------- > > > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >>>For additional commands, e-mail: [EMAIL PROTECTED] > > > >>> > > > >> > > > >>-- > > > >>Michael Stover > > > >>[EMAIL PROTECTED] > > > >>Yahoo IM: mstover_ya > > > >>ICQ: 152975688 > > > >>AIM: mstover777 > > > >> > > > >>--------------------------------------------------------------------- > > > >>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] > > > > -- > Michael Stover > [EMAIL PROTECTED] > Yahoo IM: mstover_ya > ICQ: 152975688 > AIM: mstover777 > > --------------------------------------------------------------------- > 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]
