You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Isuru Perera <ch...@gmail.com> on 2017/09/11 06:26:03 UTC
Re: Netty Client Implementation for HTTP Sampler
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-
users-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.
2. 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
I'm wondering whether we could avoid above issues with a Netty Client
Implementation instead of the default client implementation in JMeter.
WDYT?
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.mouawad@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
Re: Netty Client Implementation for HTTP Sampler
Posted by Isuru Perera <is...@apache.org>.
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 <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.mouawad@gmail.com> wrote:
>>
>>> Hello,
>>>
>>>
>>> On Mon, Sep 11, 2017 at 8:26 AM, Isuru Perera <ch...@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.mouawad@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
Re: Netty Client Implementation for HTTP Sampler
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
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.mouawad@gmail.com> wrote:
>
>> Hello,
>>
>>
>> On Mon, Sep 11, 2017 at 8:26 AM, Isuru Perera <ch...@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.mouawad@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>
Re: Netty Client Implementation for HTTP Sampler
Posted by Isuru Perera <is...@apache.org>.
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 <ch...@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 <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.mouawad@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
Re: Netty Client Implementation for HTTP Sampler
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
On Mon, Sep 11, 2017 at 8:26 AM, Isuru Perera <ch...@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.mouawad@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.
Re: Netty Client Implementation for HTTP Sampler
Posted by Isuru Perera <is...@apache.org>.
Hi sebb,
Thanks for your comments. I actually didn't know that JMeter uses blocking
HTTP requests. I have heard that Netty can handle more concurrent non
blocking connections than blocking connections. (I will try to find some
reference links later).
My only concern is that load average of the JMeter server is very high.
Have you monitored load average while running a test?
On Mon, Sep 11, 2017 at 1:22 PM, sebb <se...@gmail.com> wrote:
> On 11 September 2017 at 07:26, Isuru Perera <ch...@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.
>
> Better than what?
>
> Note also that JMeter uses blocking HTTP requests.
> It is not currently designed to use asynchronous HTTP requests.
>
> > 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-
> > users-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.
> > 2. 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
> >
> > I'm wondering whether we could avoid above issues with a Netty Client
> > Implementation instead of the default client implementation in JMeter.
> >
> > WDYT?
> >
> > 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.mouawad@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
>
--
Isuru Perera
about.me/chrishantha
Re: Netty Client Implementation for HTTP Sampler
Posted by sebb <se...@gmail.com>.
On 11 September 2017 at 07:26, Isuru Perera <ch...@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.
Better than what?
Note also that JMeter uses blocking HTTP requests.
It is not currently designed to use asynchronous HTTP requests.
> 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-
> users-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.
> 2. 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
>
> I'm wondering whether we could avoid above issues with a Netty Client
> Implementation instead of the default client implementation in JMeter.
>
> WDYT?
>
> 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.mouawad@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