jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isuru Perera <is...@apache.org>
Subject Re: Netty Client Implementation for HTTP Sampler
Date Tue, 12 Sep 2017 02:49:04 GMT
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.

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 would love to contribute to JMeter, but I need to first invest some time
to understand existing code base.

On Mon, Sep 11, 2017 at 5:08 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

> Hello,
>
>
> On Mon, Sep 11, 2017 at 8:26 AM, Isuru Perera <chrishantha@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-var
>>    y-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 <isuru@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.mouawad@gmail.com> wrote:
>>>
>>>> Hello,
>>>> Why do you want that ?
>>>> Thanks
>>>>
>>>> On Thu, Jul 20, 2017 at 3:35 PM, Isuru Perera <isuru@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 <isuru@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message