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 Fri, 15 Sep 2017 08:37:18 GMT
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.mouawad@ubik-ingenierie.com> wrote:

> Hi,
> Find my answers below.
> Regards
>
> On Tue, Sep 12, 2017 at 4:49 AM, Isuru Perera <isuru@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.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-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 <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
>>
>
>
>
> --
> 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

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