Saml Authentication is giving 500 ( Internal Server ) Error in JMeter
Hi, I am testing a website in which the authentication is getting done by a server which is different from the application server. The script runs successfully for a short period of time after recording, however I am getting 500 (Internal server) error at authentication page where iv got to receive the SAML token. The response recorded in view result tree is Run time error. When the site is accessed manually the authentication is successful. I have done the necessary correlation. I have also used HTTP Cookie Manager to handle the session. Is there any problem with the script i.e the way the request is being sent? Your expertise will be appreciated. Regards, Stephanie Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
RE: Saml Authentication is giving 500 ( Internal Server ) Error in JMeter
I have used REE in all the pages to correlate the dynamic values. However in saml page1, I am getting an authentication error. Hence I am not able to use the dynamic values of this request in the saml page2. Another point that id like to share is that even while running the script after recording I mm getting the same authentication error in saml page1, however the 2nd page is a success. This stops after some period of time i.e around 5-10 min. Regards, Stephanie -Original Message- From: Jain, Kapil [mailto:kapil.j...@logica.com] Sent: Wednesday, December 14, 2011 5:01 PM To: JMeter Users List Subject: RE: Saml Authentication is giving 500 ( Internal Server ) Error in JMeter I think you need to capture SAML Request, Response through REE. it should work fine. I have tested similar authentication and it worked fine for me. Also Use Debug sampler to verify the captured value. From: Dcunha, Stephanie [stephanie.dcu...@igatepatni.com] Sent: 14 December 2011 11:27 To: jmeter-u...@jakarta.apache.org Subject: Saml Authentication is giving 500 ( Internal Server ) Error in JMeter Hi, I am testing a website in which the authentication is getting done by a server which is different from the application server. The script runs successfully for a short period of time after recording, however I am getting 500 (Internal server) error at authentication page where iv got to receive the SAML token. The response recorded in view result tree is Run time error. When the site is accessed manually the authentication is successful. I have done the necessary correlation. I have also used HTTP Cookie Manager to handle the session. Is there any problem with the script i.e the way the request is being sent? Your expertise will be appreciated. Regards, Stephanie Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com. Think green - keep it on the screen. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional
Re: Clear authentication credentials
Hi, Try to disable the keep alive on the http sampler. Shmuel.
Re: Performance OpenJDK compared with SunJDK
Hey Looking at your configuration, here is a possible theory... Sun Microsystem (Sun JDK) was eaten by Oracle which runs on WINTEL platforms so the performance of SUN JDK is optimized on INTEL platforms. OpenJDK is meant for Linux platforms a late entry for INTEL into this game and hence low performance and high CPU peaks... Deepak On 12/14/11, Toni Menendez Lopez tonime...@gmail.com wrote: My loadserver is running in this server, Hardware : Proliant BL460C G1 2xIntel Xeon @2,53Ghz (quad) 32 GB of memory O.S : RHEL5.4(Tikanga) I don´t have stats about that but I will collect in few days that I will have again the server available, but my impression is that JMeter is taking much more CPU with OpenJDK and is doing lots of big peaks, seems problems with GC. But I will analyze it later, when my actual testing finished. Toni. 2011/12/13, Deepak Goel deic...@gmail.com: Hey Looks like an evolution and quality problem..Sun JDK more evolved v/s OpenJDK What is the hardware? What is the performance difference? Stats please... Deepak On 12/13/11, Toni Menendez Lopez tonime...@gmail.com wrote: Hello all, I want to ask all of you on question ! I am normally working with SunJDK for Jmeter and running in non-gui mode, but now I want to migrate the openJDK ( OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)). I have executed the same test in SunJDK and OpenJDK and I have experienced that Jmeter has worst performance sending the traffic with OPenJDK that with SunJDK. Any of you have got some similar experience ? My O.S is RHEL5.4 Best regards, Toni. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Clear authentication credentials
Hi Shmuel, Keep alive is already disabled. Regards, Sasidhar Sekar -- View this message in context: http://jmeter.512774.n5.nabble.com/Clear-authentication-credentials-tp5074116p5074366.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
Here's a bit of info on difference between linux and windows with regard to JVM that might explain the performance difference. Getting currentTimeMillis and nano time has a higher overhead on linux versus windows. For things like stress testing and benchmark tools like JMeter, getting time is a significant part of the application. From first hand experience, it can be as little as 2% or as high as 10% depending on how often your code gets time from the system. The bigger difference is CPU usage. I have seen linux take considerably more CPU resources when I run benchmarks on apps using unit tests, jmeter or other stress testing tools that frequently get time. On Wed, Dec 14, 2011 at 7:41 AM, Deepak Goel deic...@gmail.com wrote: Hey Looking at your configuration, here is a possible theory... Sun Microsystem (Sun JDK) was eaten by Oracle which runs on WINTEL platforms so the performance of SUN JDK is optimized on INTEL platforms. OpenJDK is meant for Linux platforms a late entry for INTEL into this game and hence low performance and high CPU peaks... Deepak On 12/14/11, Toni Menendez Lopez tonime...@gmail.com wrote: My loadserver is running in this server, Hardware : Proliant BL460C G1 2xIntel Xeon @2,53Ghz (quad) 32 GB of memory O.S : RHEL5.4(Tikanga) I don´t have stats about that but I will collect in few days that I will have again the server available, but my impression is that JMeter is taking much more CPU with OpenJDK and is doing lots of big peaks, seems problems with GC. But I will analyze it later, when my actual testing finished. Toni. 2011/12/13, Deepak Goel deic...@gmail.com: Hey Looks like an evolution and quality problem..Sun JDK more evolved v/s OpenJDK What is the hardware? What is the performance difference? Stats please... Deepak On 12/13/11, Toni Menendez Lopez tonime...@gmail.com wrote: Hello all, I want to ask all of you on question ! I am normally working with SunJDK for Jmeter and running in non-gui mode, but now I want to migrate the openJDK ( OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)). I have executed the same test in SunJDK and OpenJDK and I have experienced that Jmeter has worst performance sending the traffic with OPenJDK that with SunJDK. Any of you have got some similar experience ? My O.S is RHEL5.4 Best regards, Toni. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: jdbc connection
Just found out that jtds drivers are the best to connect to mssql db. tried that with the appropriate jars and with the following db URL and driver class. It workd perfectly fine URL: jdbc:jtds:sqlserver://db-server/db_name JDBC Driver Class : net.sourceforge.jtds.jdbc.Driver username : test password : test -Waseem -- View this message in context: http://jmeter.512774.n5.nabble.com/jdbc-connection-tp5071152p5074550.html Sent from the JMeter - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
@Peter can you please combine your two mails and restate what you are trying to point out. Seems they mean different things: -- Getting currentTimeMillis and nano time has a higher overhead on linux versus windows The difference between using currentTimeMillis versus nano time is about 20-30% overhead regardless of the operating system or version of JVM. -- Also can you please mention exactly what hardware have you measured your results for? On 12/14/11, Peter Lin wool...@gmail.com wrote: I'll add a little bit more. The difference between using currentTimeMillis versus nano time is about 20-30% overhead regardless of the operating system or version of JVM. I've seen this first hand with Sun, IBM and JRockit on windows and linux. OpenJDK is mostly the same as SunJDK, so there's very little difference from a performance perspective. the SunJDK usually doesn't include the experimental stuff that OpenJDK might have. On Wed, Dec 14, 2011 at 7:41 AM, Deepak Goel deic...@gmail.com wrote: Hey Looking at your configuration, here is a possible theory... Sun Microsystem (Sun JDK) was eaten by Oracle which runs on WINTEL platforms so the performance of SUN JDK is optimized on INTEL platforms. OpenJDK is meant for Linux platforms a late entry for INTEL into this game and hence low performance and high CPU peaks... Deepak On 12/14/11, Toni Menendez Lopez tonime...@gmail.com wrote: My loadserver is running in this server, Hardware : Proliant BL460C G1 2xIntel Xeon @2,53Ghz (quad) 32 GB of memory O.S : RHEL5.4(Tikanga) I don´t have stats about that but I will collect in few days that I will have again the server available, but my impression is that JMeter is taking much more CPU with OpenJDK and is doing lots of big peaks, seems problems with GC. But I will analyze it later, when my actual testing finished. Toni. 2011/12/13, Deepak Goel deic...@gmail.com: Hey Looks like an evolution and quality problem..Sun JDK more evolved v/s OpenJDK What is the hardware? What is the performance difference? Stats please... Deepak On 12/13/11, Toni Menendez Lopez tonime...@gmail.com wrote: Hello all, I want to ask all of you on question ! I am normally working with SunJDK for Jmeter and running in non-gui mode, but now I want to migrate the openJDK ( OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)). I have executed the same test in SunJDK and OpenJDK and I have experienced that Jmeter has worst performance sending the traffic with OPenJDK that with SunJDK. Any of you have got some similar experience ? My O.S is RHEL5.4 Best regards, Toni. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org -- Namaskara~Nalama~Guten Tag~Bonjour -- Keigu Deepak +91-9765089593 deic...@gmail.com http://www.simtree.net Skype: thumsupdeicool Google talk: deicool Blog: http://loveandfearless.wordpress.com Facebook: http://www.facebook.com/deicool Contribute to the world, environment and more : http://www.gridrepublic.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
On 14 December 2011 14:16, Peter Lin wool...@gmail.com wrote: sorry for the confusion. There's 2 issues that could result in a performance difference between OS. The first is getting time from the operating system regardless of which method one calls to get a timestamp. Back when I was active in jmeter, we used System.currentTimeMillis(). I don't know if it is still using that or the newer System.nanoTime(). By default it uses both; currentTimeMillis is used to generate start/end timestamps, and nanoTime is used to generate elapsed time. Unfortunately it turns out that nanoTime drifts quite badly relative to currentTimeMillis, so currentTimeMillis has to be used to anchor that drift. Otherwise the times just don't add up properly. The JMeter property sampleresult.useNanoTime can be set to false to disable the use of nanoTime. - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
From OpenJDK for BSD,
jlong os::javaTimeNanos() {
if (Bsd::supports_monotonic_clock()) {
struct timespec tp;
int status = Bsd::clock_gettime(CLOCK_MONOTONIC, tp);
assert(status == 0, gettime error);
jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
return result;
} else {
timeval time;
int status = gettimeofday(time, NULL);
assert(status != -1, bsd error);
jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
return 1000 * usecs;
}
}
and
jlong os::javaTimeMillis() {
timeval time;
int status = gettimeofday(time, NULL);
assert(status != -1, bsd error);
return jlong(time.tv_sec) * 1000 + jlong(time.tv_usec / 1000);
}
Window..
jlong windows_to_java_time(FILETIME wt) {
jlong a = jlong_from(wt.dwHighDateTime, wt.dwLowDateTime);
return (a - offset()) / 1;
}
FILETIME java_to_windows_time(jlong l) {
jlong a = (l * 1) + offset();
FILETIME result;
result.dwHighDateTime = high(a);
result.dwLowDateTime = low(a);
return result;
}
// For now, we say that Windows does not support vtime. I have no idea
// whether it can actually be made to (DLD, 9/13/05).
bool os::supports_vtime() { return false; }
bool os::enable_vtime() { return false; }
bool os::vtime_enabled() { return false; }
double os::elapsedVTime() {
// better than nothing, but not much
return elapsedTime();
}
jlong os::javaTimeMillis() {
if (UseFakeTimers) {
return fake_time++;
} else {
FILETIME wt;
GetSystemTimeAsFileTime(wt);
return windows_to_java_time(wt);
}
}
and
jlong os::javaTimeNanos() {
if (!has_performance_count) {
return javaTimeMillis() * NANOS_PER_MILLISEC; // the best we can do.
} else {
LARGE_INTEGER current_count;
QueryPerformanceCounter(current_count);
double current = as_long(current_count);
double freq = performance_frequency;
jlong time = (jlong)((current/freq) * NANOS_PER_SEC);
return time;
}
}
UseFakeTimers is a develop flag so it will always be false in a normal build.
Only Windows uses fake timers.
It looks as if QueryPerformanceCounter uses a TSC.
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx).
My discussions with the HotSpot team (which is currently evaluating how to use
any monotonic clock that might be available) suggests that gettimeofday uses
the RTC. While TSC is on the chip, the RTC is on a chip of it's own. So this
might account for some of the difference in performance. The MS implementation
requires thread-affinity to work where as the Linux version doesn't. That said,
I still content that thread scheduling has a bigger impact. If you run your
tests in a virtualized environment, one where the hypervisor interferes with
the thread scheduler, I think you'll see even worse performance, something that
would not be accounted for by differences in time needed to access a timer.
Regards,
Kirk
On Dec 14, 2011, at 3:16 PM, Peter Lin wrote:
sorry for the confusion.
There's 2 issues that could result in a performance difference between OS.
The first is getting time from the operating system regardless of
which method one calls to get a timestamp. Back when I was active in
jmeter, we used System.currentTimeMillis(). I don't know if it is
still using that or the newer System.nanoTime().
More succintly
1. System.nanoTime is slower than System.currentTimeMillis on all OS 20-30%
2. getting the system time on linux is slower than on windows and
solaris. I don't know about aix, hpux or mac.
3. getting nanotime on linux is slower than on windows and solaris.
4. getting either system time or nano time on linux uses more CPU than windows
The versions of windows doesn't make too much difference. I've tested
win2K, XP and 7.
On linux, it doesn't matter which distribution, since it is a feature
of the kernel. I've had discussion on this topic of henrik stahl, who
used to lead JRockit at BEA.
Since JMeter gets a timestamp at the start and end of a request, it is
getting time frequently. This easily accounts for performance
difference between running JMeter on windows versus linux. The
difference depends on your stress test.
for example, say I'm testing webpages that are small and fast average
100ms per request. The percent of time spent getting timestamp is
going to be a higher percent of the total CPU time.
In contrast, if I'm testing big webpages that take 60 seconds to load,
the percent time spent getting timestamp is less.
This is true of any kind of stress test running in Java. I've done
this with simple POJO that call a main method, JUnit tests, custom
test framework and JMeter. Basically, the performance difference a
developer might see between linux and windows with JMeter is the
result of the JVM + OS. It has nothing to do with JMeter :)
On Wed, Dec 14, 2011 at 8:59 AM, Deepak Goel deic...@gmail.com wrote:
@Peter
can you please combine
Re: Performance OpenJDK compared with SunJDK
Unfortunately it turns out that nanoTime drifts quite badly relative to currentTimeMillis, so currentTimeMillis has to be used to anchor that drift. Otherwise the times just don't add up properly. The JMeter property sampleresult.useNanoTime can be set to false to disable the use of nanoTime. Right, if nanoTime in Windows uses a TSC I would expect drift especially on newer processors. Not all cores receive all clocks and since the value in the TSC * CPu frequency is the current time, not having an accurate count of clocks would cause drift. currentTimeMillis relying on a RTC would have smaller amounts of drift which would only be noticed between machines (which would be correct with NTP). So your correction of drift would be consistent with this. On Solaris, the drift between the TOD clock and the TSC is correct after a 1ms drift 125us at a time. I think MS has attempted something similar (due to complaints from gamers) but I'm not aware of the details. Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
Great discussion by the way. Before I talked to henrik, I had no clue how complex timers are in the JVM. It was too much info to fit in my brain and got GC-ed. I can only imagine what Azul is seeing with their hardware. On Wed, Dec 14, 2011 at 10:33 AM, Kirk kirk.pepperd...@gmail.com wrote: Well, I'm not sure why he's seeing a difference in performance. I've not spoken to Henrik about timers so I can't comment on what he's telling you. I can only say that there is currently an open CR w.r.t monotonic timers and there is some discussion on the subject in the CR. I've also spoken to Cliff Click about Azul timers and to point to the confusion here.. he was certain that the JDK was using the TSC, something that I was told by Charlie Hunt wasn't the case. So I went digging to find out which of these two was right. Turns out the answer is pretty complicated as it really depends on the OS and what the hardware has. RedHat was the last to touch the OpenJDK timer code and they did so only in the Linux build and only to have the high res timer used if it was available. Not a very clear picture.. and all of these timers come with their own set of faults.. which could be worked around if only we knew which one was being used ;-) And to add to the confusion is thread scheduler efficiency which comes into play and I'm very suspicious of hypervisor interference with thread scheduling.Azul has found some very very weird (almost harmonic) interference patterns that can adversely affect the ability to utilize cores. Without access to proper counters it's almost impossible to say for sure whats going on. Regards, Kirk On Dec 14, 2011, at 4:09 PM, Peter Lin wrote: thanks kirk for digging up those details. My memory is faulty, but that is basically what henrik told me back in 2006/2007. I had noticed a difference between System.currentTimeMillis and System.nanoTime on all JVM (sun, jrockit, ibm). Digging deeper, henrik explained to me that windows uses the high performance timer, which is considerably faster than linux timer. I agree that more threads results in more pressure on the thread scheduler. what got me curious is the user sees a difference between openJDK and sunJDK. perhaps there is some other process running on that linux system contributing to the extra CPU load. On Wed, Dec 14, 2011 at 10:00 AM, Kirk kirk.pepperd...@gmail.com wrote: Unfortunately it turns out that nanoTime drifts quite badly relative to currentTimeMillis, so currentTimeMillis has to be used to anchor that drift. Otherwise the times just don't add up properly. The JMeter property sampleresult.useNanoTime can be set to false to disable the use of nanoTime. Right, if nanoTime in Windows uses a TSC I would expect drift especially on newer processors. Not all cores receive all clocks and since the value in the TSC * CPu frequency is the current time, not having an accurate count of clocks would cause drift. currentTimeMillis relying on a RTC would have smaller amounts of drift which would only be noticed between machines (which would be correct with NTP). So your correction of drift would be consistent with this. On Solaris, the drift between the TOD clock and the TSC is correct after a 1ms drift 125us at a time. I think MS has attempted something similar (due to complaints from gamers) but I'm not aware of the details. Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Idea's to add an additional layer of data security, encrypt specific information(tables) in database?
Hi there, i was wondering how we could create an addtional layer of datasecurity in case security measures like sql injection etc are bypassed? The idea is that we want to encrypt data which is relevant to user data for example.. It would be nice if we could achieve this wit offcourse minimal effort in our Grails application :) I have no idea what a recommended approach would be, is it an idea to encrypt specific tables etc?? Any suggestions? /Marco - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Idea's to add an additional layer of data security, encrypt specific information(tables) in database?
Sorry.. my apologies! Indeed a big mistake on my side!! On Dec 14, 2011 6:59 PM, sebb seb...@gmail.com wrote: On 14 December 2011 17:41, Marco Pas marco.paso...@gmail.com wrote: Hi there, i was wondering how we could create an addtional layer of datasecurity in case security measures like sql injection etc are bypassed? The idea is that we want to encrypt data which is relevant to user data for example.. It would be nice if we could achieve this wit offcourse minimal effort in our Grails application :) I have no idea what a recommended approach would be, is it an idea to encrypt specific tables etc?? Any suggestions? Not sure what this has to do with JMeter - did you post to the wrong mailing list? /Marco - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Strange 'pause' activity during testing
I have a marginally complicated test case that performs a 'registration' on my site. It gets the home page, POSTS a form, gets the response, POSTS another form, gets that response, and then completes. The test runs fine with 100 threads, and 3 iterations - IF I don't Retrieve All Embedded Resources from HTML Files. In this mode, I am really testing the throughput of my 'tomcat' application, not the other elements of my system. (I'm assuming that the other elements are being retrieved from our Content Data Network instead of our main system in this case.) If I enable the Retrieve All Embedded Resources from HTML Files flag, and tune the test down to 10 threads with 3000 total iterations, I notice a very strange behavior. The test runs along at a pretty good clip for the first ~600 iterations (about 1 min, 25 seconds into the run), and then it just stops making requests for about 35 seconds. Then, it picks back up again and runs for another 1 m 25s, and then stops again for 35 seconds... (NOTE: with the 10 threads, 3000 total iterations - but with Retrieve All Embedded... disabled - I don't see the 'stop' behavior either - so it isn't caused by tuning it down...) I recently added the Perfmon Metrics Collector to the test script, so I could see if one of the servers was maxed out - but it looks like all the servers are idle during the 'stop' period. Likewise, I added the Perfmon for the localhost (running the JMeter test) to see if it was swamped - but it too is idle during the 'stop'. I swapped out our network switch (the test environment is on an isolated network switch) with a _much_ higher capacity switch - in case there was a network issue, still no change. I'm running out of ideas for things to check - so I thought I'd ask you guys if you have any suggestions of things I should look at. My system consists of: WinXP - running JMeter 2.4.1 - driving the test script in GUI mode Server 1 - running Red Hat Linux, with Apache (2.2.21) as the web server - using AJP Proxy to Server 2 Server 2 - running Red Hat Linux, with Tomcat 7.0.21 as the App Server - connecting through Hibernate to Server 3 Server 3 - running Red Hat Linux with MySQL 5.x as the DB Server All 4 machines are running on a private switched network (32Gbs backplane). The requests are downloading about 3MB total (per thread per iteration) over 4 main URL requests, and 30+ 'Retrieve All Embedded' requests. At first I thought it was the network - but the new switch seemed to deny that thought (the old switch had a much slower backplane). Also, I'm having no trouble collecting the PerfMon data during the 'stop' period - so the network is still functioning just fine... Then I thought it might be garbage collection on the tomcat - but I watched the gc.log - and it doesn't do any GCs during the 'stop' period. Then I thought it might be the garbage collection on the JMeter side, so I started the JMeter.bat from a 'cmd' prompt with gc logging enabled - it doesn't do any GCs during the 'stop' period either. The apache, tomcat, and DB are all 'idle' (no CPU to speak of, no network I/O, no disk I/O, etc.) during the 'stop' period. The JMeter box (WinXP) is doing very little during that time too (I attribute the little bit of activity to displaying the PerfMon graphs, and Remote Desktop display to my desktop computer)... -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Performance OpenJDK compared with SunJDK
Thanks all for the contribution to the issue, Next week I will launch again the same test, and I will add GCLogs to Jmeter, and I will compare GC results for both cases to see if really the JVM is working different. Thks, Toni El 14/12/2011, a las 16:40, Peter Lin wool...@gmail.com escribió: Great discussion by the way. Before I talked to henrik, I had no clue how complex timers are in the JVM. It was too much info to fit in my brain and got GC-ed. I can only imagine what Azul is seeing with their hardware. On Wed, Dec 14, 2011 at 10:33 AM, Kirk kirk.pepperd...@gmail.com wrote: Well, I'm not sure why he's seeing a difference in performance. I've not spoken to Henrik about timers so I can't comment on what he's telling you. I can only say that there is currently an open CR w.r.t monotonic timers and there is some discussion on the subject in the CR. I've also spoken to Cliff Click about Azul timers and to point to the confusion here.. he was certain that the JDK was using the TSC, something that I was told by Charlie Hunt wasn't the case. So I went digging to find out which of these two was right. Turns out the answer is pretty complicated as it really depends on the OS and what the hardware has. RedHat was the last to touch the OpenJDK timer code and they did so only in the Linux build and only to have the high res timer used if it was available. Not a very clear picture.. and all of these timers come with their own set of faults.. which could be worked around if only we knew which one was being used ;-) And to add to the confusion is thread scheduler efficiency which comes into play and I'm very suspicious of hypervisor interference with thread scheduling.Azul has found some very very weird (almost harmonic) interference patterns that can adversely affect the ability to utilize cores. Without access to proper counters it's almost impossible to say for sure whats going on. Regards, Kirk On Dec 14, 2011, at 4:09 PM, Peter Lin wrote: thanks kirk for digging up those details. My memory is faulty, but that is basically what henrik told me back in 2006/2007. I had noticed a difference between System.currentTimeMillis and System.nanoTime on all JVM (sun, jrockit, ibm). Digging deeper, henrik explained to me that windows uses the high performance timer, which is considerably faster than linux timer. I agree that more threads results in more pressure on the thread scheduler. what got me curious is the user sees a difference between openJDK and sunJDK. perhaps there is some other process running on that linux system contributing to the extra CPU load. On Wed, Dec 14, 2011 at 10:00 AM, Kirk kirk.pepperd...@gmail.com wrote: Unfortunately it turns out that nanoTime drifts quite badly relative to currentTimeMillis, so currentTimeMillis has to be used to anchor that drift. Otherwise the times just don't add up properly. The JMeter property sampleresult.useNanoTime can be set to false to disable the use of nanoTime. Right, if nanoTime in Windows uses a TSC I would expect drift especially on newer processors. Not all cores receive all clocks and since the value in the TSC * CPu frequency is the current time, not having an accurate count of clocks would cause drift. currentTimeMillis relying on a RTC would have smaller amounts of drift which would only be noticed between machines (which would be correct with NTP). So your correction of drift would be consistent with this. On Solaris, the drift between the TOD clock and the TSC is correct after a 1ms drift 125us at a time. I think MS has attempted something similar (due to complaints from gamers) but I'm not aware of the details. Regards, Kirk - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Strange 'pause' activity during testing
might be GC.. me be that JMeter's threads are all hung up in your server doing stuff. Regards, Kirk On Dec 14, 2011, at 10:35 PM, Robin D. Wilson wrote: I have a marginally complicated test case that performs a 'registration' on my site. It gets the home page, POSTS a form, gets the response, POSTS another form, gets that response, and then completes. The test runs fine with 100 threads, and 3 iterations - IF I don't Retrieve All Embedded Resources from HTML Files. In this mode, I am really testing the throughput of my 'tomcat' application, not the other elements of my system. (I'm assuming that the other elements are being retrieved from our Content Data Network instead of our main system in this case.) If I enable the Retrieve All Embedded Resources from HTML Files flag, and tune the test down to 10 threads with 3000 total iterations, I notice a very strange behavior. The test runs along at a pretty good clip for the first ~600 iterations (about 1 min, 25 seconds into the run), and then it just stops making requests for about 35 seconds. Then, it picks back up again and runs for another 1 m 25s, and then stops again for 35 seconds... (NOTE: with the 10 threads, 3000 total iterations - but with Retrieve All Embedded... disabled - I don't see the 'stop' behavior either - so it isn't caused by tuning it down...) I recently added the Perfmon Metrics Collector to the test script, so I could see if one of the servers was maxed out - but it looks like all the servers are idle during the 'stop' period. Likewise, I added the Perfmon for the localhost (running the JMeter test) to see if it was swamped - but it too is idle during the 'stop'. I swapped out our network switch (the test environment is on an isolated network switch) with a _much_ higher capacity switch - in case there was a network issue, still no change. I'm running out of ideas for things to check - so I thought I'd ask you guys if you have any suggestions of things I should look at. My system consists of: WinXP - running JMeter 2.4.1 - driving the test script in GUI mode Server 1 - running Red Hat Linux, with Apache (2.2.21) as the web server - using AJP Proxy to Server 2 Server 2 - running Red Hat Linux, with Tomcat 7.0.21 as the App Server - connecting through Hibernate to Server 3 Server 3 - running Red Hat Linux with MySQL 5.x as the DB Server All 4 machines are running on a private switched network (32Gbs backplane). The requests are downloading about 3MB total (per thread per iteration) over 4 main URL requests, and 30+ 'Retrieve All Embedded' requests. At first I thought it was the network - but the new switch seemed to deny that thought (the old switch had a much slower backplane). Also, I'm having no trouble collecting the PerfMon data during the 'stop' period - so the network is still functioning just fine... Then I thought it might be garbage collection on the tomcat - but I watched the gc.log - and it doesn't do any GCs during the 'stop' period. Then I thought it might be the garbage collection on the JMeter side, so I started the JMeter.bat from a 'cmd' prompt with gc logging enabled - it doesn't do any GCs during the 'stop' period either. The apache, tomcat, and DB are all 'idle' (no CPU to speak of, no network I/O, no disk I/O, etc.) during the 'stop' period. The JMeter box (WinXP) is doing very little during that time too (I attribute the little bit of activity to displaying the PerfMon graphs, and Remote Desktop display to my desktop computer)... -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Re: Strange 'pause' activity during testing
I think the original post mentioned that GC was not running. can you take a thread dump when there is a pause and see what the threads are waiting on? On Wed, Dec 14, 2011 at 1:56 PM, Kirk kirk.pepperd...@gmail.com wrote: might be GC.. me be that JMeter's threads are all hung up in your server doing stuff. Regards, Kirk On Dec 14, 2011, at 10:35 PM, Robin D. Wilson wrote: I have a marginally complicated test case that performs a 'registration' on my site. It gets the home page, POSTS a form, gets the response, POSTS another form, gets that response, and then completes. The test runs fine with 100 threads, and 3 iterations - IF I don't Retrieve All Embedded Resources from HTML Files. In this mode, I am really testing the throughput of my 'tomcat' application, not the other elements of my system. (I'm assuming that the other elements are being retrieved from our Content Data Network instead of our main system in this case.) If I enable the Retrieve All Embedded Resources from HTML Files flag, and tune the test down to 10 threads with 3000 total iterations, I notice a very strange behavior. The test runs along at a pretty good clip for the first ~600 iterations (about 1 min, 25 seconds into the run), and then it just stops making requests for about 35 seconds. Then, it picks back up again and runs for another 1 m 25s, and then stops again for 35 seconds... (NOTE: with the 10 threads, 3000 total iterations - but with Retrieve All Embedded... disabled - I don't see the 'stop' behavior either - so it isn't caused by tuning it down...) I recently added the Perfmon Metrics Collector to the test script, so I could see if one of the servers was maxed out - but it looks like all the servers are idle during the 'stop' period. Likewise, I added the Perfmon for the localhost (running the JMeter test) to see if it was swamped - but it too is idle during the 'stop'. I swapped out our network switch (the test environment is on an isolated network switch) with a _much_ higher capacity switch - in case there was a network issue, still no change. I'm running out of ideas for things to check - so I thought I'd ask you guys if you have any suggestions of things I should look at. My system consists of: WinXP - running JMeter 2.4.1 - driving the test script in GUI mode Server 1 - running Red Hat Linux, with Apache (2.2.21) as the web server - using AJP Proxy to Server 2 Server 2 - running Red Hat Linux, with Tomcat 7.0.21 as the App Server - connecting through Hibernate to Server 3 Server 3 - running Red Hat Linux with MySQL 5.x as the DB Server All 4 machines are running on a private switched network (32Gbs backplane). The requests are downloading about 3MB total (per thread per iteration) over 4 main URL requests, and 30+ 'Retrieve All Embedded' requests. At first I thought it was the network - but the new switch seemed to deny that thought (the old switch had a much slower backplane). Also, I'm having no trouble collecting the PerfMon data during the 'stop' period - so the network is still functioning just fine... Then I thought it might be garbage collection on the tomcat - but I watched the gc.log - and it doesn't do any GCs during the 'stop' period. Then I thought it might be the garbage collection on the JMeter side, so I started the JMeter.bat from a 'cmd' prompt with gc logging enabled - it doesn't do any GCs during the 'stop' period either. The apache, tomcat, and DB are all 'idle' (no CPU to speak of, no network I/O, no disk I/O, etc.) during the 'stop' period. The JMeter box (WinXP) is doing very little during that time too (I attribute the little bit of activity to displaying the PerfMon graphs, and Remote Desktop display to my desktop computer)... -- Robin D. Wilson Sr. Director of Web Development KingsIsle Entertainment, Inc. VOICE: 512-777-1861 www.KingsIsle.com - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
jmeter :Invocation Java sampler as maven goal
Hello All, I have a Spring Batch Job module. I am trying to test the same using JMeter using information provided below link http://henry-tech-notes.blogspot.com/2006/10/testing-hessian-services-with-jmeter.html I created a wrapper program BatchJobTest (extending org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient) and Invoked the spring batch job. I am able to test the batch job by running it from jmeter GUI. My next step would be to use the jmeter script in jmeter - Hudson plunin. https://wiki.jenkins-ci.org/display/JENKINS/Performance+Plugin while doing so , jmeter maven plugin fails by giving the below error 2011/12/15 13:16:37 ERROR - jmeter.protocol.java.sampler.JavaSampler: Thread Group 1-1@1ea25b6-Java Request Exception creating: com.sg.itec.arc.jmeter.BatchJobTest java.lang.ClassNotFoundException: com.sg.itec.arc.jmeter.BatchJobTest at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.apache.jmeter.protocol.java.sampler.JavaSampler.createJavaClient(JavaSampler.java:183) at org.apache.jmeter.protocol.java.sampler.JavaSampler.sample(JavaSampler.java:157) at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:290) at java.lang.Thread.run(Thread.java:662) Any idea on how to use the Jmeter Java Sampler in conjunction with Maven/Hudson ? Regards, Santosh ** This message and any attachments (the message) are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ** - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
