Am 19.08.20 um 12:34 schrieb Barcode S K: > I was using the "system" look and feel, and still had the problem. Maybe > one of the new builds will help. > > Could you help me figure out why there is this additional overhead when I > run with think time? TTL is now 60 seconds and my runs are less than 60 > seconds long. The overhead has reduced by 5 ms (currently at 6 ms), but it > is still there. What could be the reason? I run exactly the same thing with > exactly the same number of VUs on the very same system, just with and > without think time.
There can be a lot of reasons (meaning I don't know :)), but if you have a minimal test plan that shows that behaviour, we could look into it. Felix > > -SK > > On Wed, Aug 19, 2020 at 2:38 PM Felix Schumacher < > [email protected]> wrote: > >> Am 19.08.20 um 09:33 schrieb Barcode S K: >>> Thank you, Felix. This should help. >>> >>> I tried running the same tests through JMeter 5.3. It is true- the >>> connections were not reopened. That's a great change! >>> I believe there is still a problem, though. I earlier had response times >> of >>> 31 ms without think, and 42 ms with think. Now it's 31 and 37, and it is >>> consistent. An improvement- but the question still remains why the extra >> 6 >>> ms. The impact becomes more pronounced when there is high latency. In the >>> tests that I am referencing here, I have had to deal with just 40-45 >>> microseconds of latency (everything is on the same host). >> A minimal test plan to reproduce such issues is always good to have. >>> >>> I have had some problems with JMeter 5.3 because of which I went back to >>> 5.2. I will start a different thread for this. I will just give you an >> idea >>> of what I see every time a load test ends with 5.3. >>> >>> Tidying up ... @ Wed Aug 19 12:49:45 IST 2020 (1597821585946) >>> ... end of run >>> The JVM should have exited but did not. >>> The following non-daemon threads are still running (DestroyJavaVM is OK): >>> Thread[DestroyJavaVM,5,main], stackTrace: >>> Thread[AWT-EventQueue-0,6,main], stackTrace:sun.misc.Unsafe#park >>> java.util.concurrent.locks.LockSupport#park at line:175 >>> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject#await >>> at line:2039 >>> java.awt.EventQueue#getNextEvent at line:554 >>> java.awt.EventDispatchThread#pumpOneEventForFilters at line:187 >>> java.awt.EventDispatchThread#pumpEventsForFilter at line:116 >>> java.awt.EventDispatchThread#pumpEventsForHierarchy at line:105 >>> java.awt.EventDispatchThread#pumpEvents at line:101 >>> java.awt.EventDispatchThread#pumpEvents at line:93 >>> java.awt.EventDispatchThread#run at line:82 >>> >>> Thread[AWT-Shutdown,5,system], stackTrace:java.lang.Object#wait >>> sun.awt.AWTAutoShutdown#run at line:314 >>> java.lang.Thread#run at line:748 >> We had some problems with the new default LAF, which might lead to >> unexpected problems in GUI Mode (affects 5.3). You can try to run a >> nightly build (where the bugs should be fixed) or switch to a >> non-darklaf mode. >> >> Felix >> >>> ^C >>> >>> This error has appeared on all (three) Linux VMs (Oracle Linux) that I've >>> tried, plus on my Windows system that had a previous installation of >>> JMeter. I did not encounter this error while running it on another >> Windows >>> server that had never had JMeter installed on it. >>> >>> >>> >>> >>> On Tue, Aug 18, 2020 at 10:38 PM Felix Schumacher < >>> [email protected]> wrote: >>> >>>> Am 18.08.20 um 18:18 schrieb Barcode S K: >>>>> Hello, >>>>> >>>>> I recently recorded my application with JMeter. >>>> Which version of JMeter are you using? >>>> >>>>> - The application is SSL-enabled. >>>>> - Application launch, login, and a screen launch are inside a >>>> Once-Only >>>>> Controller. >>>>> - The actual *transaction*- which involves just one POST request- is >>>> in >>>>> a separate transaction controller. >>>>> - Sleep time of 1 second is configured. >>>>> >>>>> >>>>> I have been running 1 VU tests, and I have observed that (for the >>>>> *transaction* alone): >>>>> >>>>> 1. While running with think time, average response time is about 42 >>>> ms. >>>>> 2. While running without think time, average response time is 31 ms. >>>>> >>>>> To eliminate latency and excess load, I am running only 1 VU tests for >>>>> 30-60 seconds on the same machine that hosts the application. I have >>>>> observed (via netstat) that JMeter opens a new connection every 2-3 >>>> seconds >>>>> and I believe the overhead of new handshakes plus the SSL handshake >> (and >>>>> other connection-related processing) is the reason between this >>>> difference. >>>> >>>> We changed the default for httpclient4.time_to_live to 60000. If you are >>>> not using the newest version (which is 5.3 or you can try a nightly >>>> build), make sure, that you have not overwritten that setting locally. >>>> >>>> The change was tracked with >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64289. >>>> >>>> Hope this helps >>>> >>>> Felix >>>> >>>>> I have not seen this behavior with other tools like NeoLoad and OATS. >> In >>>>> those tools, when an application that has sessions is run in a load >> test, >>>>> there is only one socket (connection) per virtual client and it remains >>>>> open throughout the run. >>>>> >>>>> Is there any way to ensure that JMeter does not open new sockets for >> new >>>>> requests in the middle of the run like this? Keep-alive is enabled for >>>> HTTP >>>>> requests. >>>>> >>>>> -SK >>>>> >> --------------------------------------------------------------------- >> 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]
