Hi Philippe, Thanks a lot for your comments.
I tested on EC2. I followed best practices in http://jmeter.apache.org/usermanual/best-practices.html. For example, I used non-GUI mode and I only have one HTTP sampler in the test. I still couldn't find time to see why JMeter load average high. Next time, I will try to profile JMeter and see where the CPU was consumed etc. I actually mentioned about JMeter Architecture as each user is a thread in JMeter. I think more threads might have an impact to the load average, but I cannot confirm without having data to prove it. I'm also hoping to try out off-cpu flamegraphs as explained in http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html I will reply once I have flamegraphs, CPU profiling data, etc. Please note that it will take some more time :) Thanks for your help. Best Regards, On Tue, Sep 12, 2017 at 7:13 PM, Philippe Mouawad < p.moua...@ubik-ingenierie.com> wrote: > Hi, > Find my answers below. > Regards > > On Tue, Sep 12, 2017 at 4:49 AM, Isuru Perera <is...@apache.org> wrote: > >> Hi Philippe, >> >> Thanks a lot for your comments >> >> I have actually tested concurrent users up to 2000 in non-GUI mode and I >> didn't have any issues. As I mentioned earlier, the load average of the >> JMeter server is very high. Therefore I wanted to find out why the load >> average is very high. One reason could be that there is one thread per >> user. So, 2000 users mean 2000 threads, which can be very high for a server >> to handle. Could you also please check the load average of the server when >> you are running a test with more than 1000 concurrent users? I hope you >> will also observe high load average. >> > No it is not high, if it was I would be worried :-) about the accurateness > of my results. > > What is the configuration of your server ? > Are you following best-practices in tests , scripting, configuration ? > Did you make some thread dumps or profile to see where CPU was consumed > for example ? > Could you share your plan ? privately ? > > >> >> Most people I work with are really concerned about the load average. Since >> one thread per user is a core part of JMeter architecture, I thought may be >> using an asynchronous HTTP client like Netty will help to reduce the load >> average of the server. That's why I started this mail thread. >> > > I understand and as I wrote your thinking is good for me, but the > correlation you make between High Load and JMeter architecture might not be > correct. > > If I had to create a whole new JMeter today , I would go for a different > architecture, still I use JMeter for pretty high loads without issues and > keep in mind that once you've set aside CPU consumption, a machine has > other limitations particularly on network side. > > >> I would love to contribute to JMeter, but I need to first invest some >> time to understand existing code base. >> > Absolutely. If you need help, feel free to ask questions. > And as usual, start with small issues, medium then big pieces to get > comfortable with code. > > >> >> On Mon, Sep 11, 2017 at 5:08 PM, Philippe Mouawad < >> philippe.moua...@gmail.com> wrote: >> >>> Hello, >>> >>> >>> On Mon, Sep 11, 2017 at 8:26 AM, Isuru Perera <chrishan...@gmail.com> >>> wrote: >>> >>>> Hi Philippe, >>>> >>>> I'm sorry for not explaining my reasons sooner. >>>> >>>> So, the main reason for asking about a Netty Client Implementation for >>>> HTTP Sampler is that Netty is supposed to be better at working under large >>>> number of concurrent non blocking connections. >>>> >>>> The main issues we are having with current HTTP Sampler are: >>>> >>>> 1. Load Average of the JMeter instance is very high. See thread: >>>> http://www.jmeter-archive.org/Maximum-number-of-concurrent-u >>>> sers-td5726006.html >>>> >>>> <http://www.jmeter-archive.org/Maximum-number-of-concurrent-users-td5726006.html>. >>>> Even for low number of concurrent users (eg, 300), if there is no timers >>>> added to the test plan, the load average of the client goes beyond >>>> acceptable limits. >>>> >>>> Not being able to go above 300 threads is due to wrong configuration, >>> bad scripting practices, GUI usage ... >>> For example, In our experience, on a 8vCPU, 16 Gb RAM, you can easily go >>> up to 2000 / 3000 threads depending on test. Have a look on recent >>> benchmarks done on last JMeter versions. >>> So I think this particular case is not relevant. >>> >>>> >>>> >>>> 1. With the default value for "httpclient4.time_to_live", we see >>>> very high response times. When we increase the time_to_live value for 30 >>>> minutes to keep a fixed number of connections, the response times are >>>> much >>>> better. See also http://www.jmeter-archive.org/ >>>> Number-of-open-connections-vary-with-time-tp5726000p5726123.html >>>> >>>> <http://www.jmeter-archive.org/Number-of-open-connections-vary-with-time-tp5726000p5726123.html> >>>> >>>> >>> The default value for "httpclient4.time_to_live" is by definition a >>> "default" value, we configure it to something that looks reasonable as an >>> average, but it must of course be tuned depending on server. >>> >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ----------------------- >>> # Idle connection timeout (Milliseconds) to apply if the server does >>> not send >>> # Keep-Alive headers (default 0) >>> # Set this > 0 to compensate for servers that don't send a Keep-Alive >>> header >>> # If <= 0, idle timeout will only apply if the server sends a Keep-Alive >>> header >>> >>> #httpclient4.idletimeout=0 >>> >>> # Check connections if the elapsed time (Milliseconds) since the last >>> # use of the connection exceed this value >>> #httpclient4.validate_after_inactivity=1700 >>> >>> # TTL (in Milliseconds) represents an absolute value. >>> # No matter what, the connection will not be re-used beyond its TTL. >>> #httpclient4.time_to_live=2000 >>> >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ----------------------- >>> >>> I'm wondering whether we could avoid above issues with a Netty Client >>>> Implementation instead of the default client implementation in JMeter. >>>> >>>> WDYT? >>>> >>> I don't think so, as they are unrelated for me. >>> >>> But of course, this does not mean that your idea is bad. And of course >>> Netty would be a good candidate for an AsyncHttpSampler or HTTP/2 as long >>> as HC5. >>> >>> If you're willing to invest some time on HTTP/2 implementation of a >>> sampler within JMeter (which could involve some rework in JMeter) you're >>> more than welcome. >>> >>> Thanks for your proposal >>> >>>> Thank you. >>>> >>>> On Tue, Jul 25, 2017 at 10:44 AM, Isuru Perera <is...@apache.org> >>>> wrote: >>>> >>>>> Hi Philippe, >>>>> >>>>> I'm sorry about the delay. I'll send a mail explaining the reasons >>>>> soon. >>>>> >>>>> On Fri, Jul 21, 2017 at 12:30 AM, Philippe Mouawad < >>>>> philippe.moua...@gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> Why do you want that ? >>>>>> Thanks >>>>>> >>>>>> On Thu, Jul 20, 2017 at 3:35 PM, Isuru Perera <is...@apache.org> >>>>>> wrote: >>>>>> >>>>>> > Hi all, >>>>>> > >>>>>> > I found a Netty client implementation for HTTP2: >>>>>> > https://github.com/syucream/jmeter-http2-plugin. However, I >>>>>> couldn't find >>>>>> > a >>>>>> > Netty client implementation for HTTP Sampler. >>>>>> > >>>>>> > On Wed, Jul 19, 2017 at 3:32 PM, Isuru Perera <is...@apache.org> >>>>>> wrote: >>>>>> > >>>>>> > > Hi Devs, >>>>>> > > >>>>>> > > Is there a Netty client implementation for HTTP Sampler either >>>>>> using >>>>>> > Netty >>>>>> > > directly or using https://github.com/AsyncHttpCl >>>>>> ient/async-http-client? >>>>>> > > >>>>>> > > -- >>>>>> > > Isuru Perera >>>>>> > > about.me/chrishantha >>>>>> > > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Isuru Perera >>>>>> > about.me/chrishantha >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cordialement. >>>>>> Philippe Mouawad. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Isuru Perera >>>>> about.me/chrishantha >>>>> >>>> >>>> >>>> >>>> -- >>>> Isuru Perera >>>> about.me/chrishantha >>>> >>> >>> >>> >>> -- >>> Cordialement. >>> Philippe Mouawad. >>> >>> >>> >> >> >> -- >> Isuru Perera >> about.me/chrishantha >> > > > > -- > Cordialement. > Philippe Mouawad. > Ubik-Ingénierie > > UBIK LOAD PACK Web Site <http://www.ubikloadpack.com/> > > UBIK LOAD PACK on TWITTER <https://twitter.com/ubikloadpack> > > -- Isuru Perera about.me/chrishantha
