You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Felix Schumacher <fe...@internetallee.de> on 2015/01/31 14:19:03 UTC
Re: JMeter Roadmap for 2014/2015
Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
> Hello,
> I think it would be a good idea to fix a roadmap for next releases of
> JMeter so that we can concentrate our work on prioritary features.
>
> My prioritary ideas are the following:
>
> - Rework architecture to be able to use a pool of threads instead of
> thread or use Reactor Pattern (
> http://reactor.github.io/docs/api/reactor/timer/SimpleHashWheelTimer.html
> )
Maybe we could/have to convert the test elements to take a context
instead of cloning them for every thread. I believe we can save a lot of
memory that way. I think we have to do something in this respect.
> - Introduce Http Client async feature or at least use one HttpClient for
> all threads
I think it would be nice to have parallel http requests for one thread
(simulated user) to be able to simulate the requests of a browser more
accurately.
> - Support Websocket and SPDY2 (bugzilla for those, but they depend on
> first 2)
> - Create an Async listener + a pluggable one (to allow Graphite /JDBC
> plugins) , see https://issues.apache.org/bugzilla/show_bug.cgi?id=55932
> . I made progress but didn't commit work yet
> - Fix known bugs in REDO/UNDO new feature
> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
Another thing I think we should consider is a StreamProcessor, which can
be used to look/modify the results of a sampler as they happen, instead
of a PostProcessor, which gets all the data after the sampler has got
it. That would enable us for example to compute the md5 sum for large
streaming data, or validate that streaming data, without using too much
memory.
I would like to see more imap sampler possibilities, like quota, status,
search to be able to put an imap server under load.
There is a wiki page which holds a "roadmap", should we update our ideas
there?
Regards
Felix
>
> I suggest everyone enhances this roadmap and we vote to decide on the
> priorities.
>
> Thoughts ?
>
Re: JMeter Roadmap for 2014/2015
Posted by sebb <se...@gmail.com>.
On 30 August 2015 at 14:59, Felix Schumacher
<fe...@internetallee.de> wrote:
> Am 30.08.2015 um 13:47 schrieb sebb:
>>
>> On 30 August 2015 at 12:07, Felix Schumacher
>> <fe...@internetallee.de> wrote:
>>>
>>> Am 30.08.2015 um 12:33 schrieb sebb:
>>>>
>>>> Thanks for the bump.
>>>>
>>>> As mentioned in the thread, it would be useful to have a Wiki page or
>>>> SVN document (or several) where the ideas can be fleshed out.
>>>> In particular, the architecture rework and shared samplers would have
>>>> a major impact on the design and 3rd party samplers, as well as being
>>>> a lot of work.
>>>>
>>>> I am always more wary about changes that affect the whole of JMeter
>>>> compared with new test elements.
>>>> This is because the knock-on effects are very difficult to forsee.
>>>> I think we tend to underestimate the amount of work needed to complete
>>>> a feature, for example Undo/Redo.
>>>> Optional addons are less of a risk, but of course still need
>>>> documentation, maintenance and user support.
>>>> This is why I have often been resistant to new features that are
>>>> relatively specialised.
>>>>
>>>> I won't comment on individual features here because the thread will
>>>> get impossible to follow.
>>>
>>> There is already a (very old) page with ideas to implement
>>> (https://wiki.apache.org/jmeter/FutureReleases) which could be a starting
>>> page to fetch up with the current state of jmeter.
>>>
>>> I think a svn based plan would be nice, too. As it would be a bit more
>>> official. Something like roadmap.txt in the main dir?
>>
>> I think it would be better to have it in a separate part of SVN, not
>> as part of trunk (it's not intended for release)
>> It could be under branches, or it could be top-level.
>> Just not tags nor trunk please.
>>
>> Also there should be a single page for each idea.
>
> I think it branches is not the right place, since I expect complete branches
> there. So a top level would be more appropriate, but it still feels wrong to
> me.
Since it is meta-information for the whole project, and not
version-specific, it seems fine to me.
There is a PMC only SVN area also but that is private.
> Maybe place (hide) it inside xdocs?
No, that's not appropriate as it will still be released.
Also it applies to all future releases, not just current trunk.
>>
>>> I would try to update the wiki page, but my (newly created) account
>>> "fschumacher" is not allowed to change anything :)
>>
>> Should be able to now.
>
> I have added the ideas to the page FutureReleases. They contain links to
> pages where discussion on each idea can take place.
>
> The list has not been updated since 2009, so there will be quite a few
> things, that jmeter is capable of by now and can be removed.
>
> Regards
> Felix
>
>>
>>> Regards,
>>> Felix
>>>
>>>>
>>>> On 30 August 2015 at 07:34, Philippe Mouawad
>>>> <ph...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Bumping for sebb as he requested it in another thread.
>>>>>
>>>>>
>>>>> On Saturday, January 31, 2015, Philippe Mouawad
>>>>> <ph...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> +1 for all your suggestions.
>>>>>>
>>>>>> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
>>>>>> felix.schumacher@internetallee.de
>>>>>> <javascript:_e(%7B%7D,'cvml','felix.schumacher@internetallee.de');>>
>>>>>> wrote:
>>>>>>
>>>>>>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I think it would be a good idea to fix a roadmap for next releases
>>>>>>>> of
>>>>>>>> JMeter so that we can concentrate our work on prioritary features.
>>>>>>>>
>>>>>>>> My prioritary ideas are the following:
>>>>>>>>
>>>>>>>> - Rework architecture to be able to use a pool of threads
>>>>>>>> instead
>>>>>>>> of
>>>>>>>> thread or use Reactor Pattern (
>>>>>>>> http://reactor.github.io/docs/api/reactor/timer/
>>>>>>>> SimpleHashWheelTimer.html
>>>>>>>> )
>>>>>>>>
>>>>>>> Maybe we could/have to convert the test elements to take a context
>>>>>>> instead of cloning them for every thread. I believe we can save a lot
>>>>>>> of
>>>>>>> memory that way. I think we have to do something in this respect.
>>>>>>>
>>>>>>> - Introduce Http Client async feature or at least use one
>>>>>>> HttpClient
>>>>>>>>
>>>>>>>> for
>>>>>>>> all threads
>>>>>>>>
>>>>>>> I think it would be nice to have parallel http requests for one
>>>>>>> thread
>>>>>>> (simulated user) to be able to simulate the requests of a browser
>>>>>>> more
>>>>>>> accurately.
>>>>>>>
>>>>>>> - Support Websocket and SPDY2 (bugzilla for those, but they
>>>>>>> depend
>>>>>>> on
>>>>>>>>
>>>>>>>> first 2)
>>>>>>>> - Create an Async listener + a pluggable one (to allow
>>>>>>>> Graphite
>>>>>>>> /JDBC
>>>>>>>> plugins) , see https://issues.apache.org/
>>>>>>>> bugzilla/show_bug.cgi?id=55932
>>>>>>>
>>>>>>>
>>>>>>>> . I made progress but didn't commit work yet
>>>>>>>>
>>>>>>> Done since then
>>>>>
>>>>>
>>>>>> - Fix known bugs in REDO/UNDO new feature
>>>>>>>>
>>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>>>>>>>> - Fix
>>>>>>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>>>>>>>
>>>>>>> Another thing I think we should consider is a StreamProcessor, which
>>>>>>> can
>>>>>>> be used to look/modify the results of a sampler as they happen,
>>>>>>> instead
>>>>>>> of
>>>>>>> a PostProcessor, which gets all the data after the sampler has got
>>>>>>> it.
>>>>>>> That
>>>>>>> would enable us for example to compute the md5 sum for large
>>>>>>> streaming
>>>>>>> data, or validate that streaming data, without using too much memory.
>>>>>>>
>>>>>>> I would like to see more imap sampler possibilities, like quota,
>>>>>>> status,
>>>>>>> search to be able to put an imap server under load.
>>>>>>>
>>>>>>> There is a wiki page which holds a "roadmap", should we update our
>>>>>>> ideas
>>>>>>> there?
>>>>>>>
>>>>>> Yes good idea.
>>>>>>
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>
>>>>>>>
>>>>>>>> I suggest everyone enhances this roadmap and we vote to decide on
>>>>>>>> the
>>>>>>>> priorities.
>>>>>>>>
>>>>>>>> Thoughts ?
>>>>>>>>
>>>>>>>>
>>>>>> --
>>>>>> Cordialement.
>>>>>> Philippe Mouawad.
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Cordialement.
>>>>> Philippe Mouawad.
>>>
>>>
>
Re: JMeter Roadmap for 2014/2015
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 30.08.2015 um 13:47 schrieb sebb:
> On 30 August 2015 at 12:07, Felix Schumacher
> <fe...@internetallee.de> wrote:
>> Am 30.08.2015 um 12:33 schrieb sebb:
>>> Thanks for the bump.
>>>
>>> As mentioned in the thread, it would be useful to have a Wiki page or
>>> SVN document (or several) where the ideas can be fleshed out.
>>> In particular, the architecture rework and shared samplers would have
>>> a major impact on the design and 3rd party samplers, as well as being
>>> a lot of work.
>>>
>>> I am always more wary about changes that affect the whole of JMeter
>>> compared with new test elements.
>>> This is because the knock-on effects are very difficult to forsee.
>>> I think we tend to underestimate the amount of work needed to complete
>>> a feature, for example Undo/Redo.
>>> Optional addons are less of a risk, but of course still need
>>> documentation, maintenance and user support.
>>> This is why I have often been resistant to new features that are
>>> relatively specialised.
>>>
>>> I won't comment on individual features here because the thread will
>>> get impossible to follow.
>> There is already a (very old) page with ideas to implement
>> (https://wiki.apache.org/jmeter/FutureReleases) which could be a starting
>> page to fetch up with the current state of jmeter.
>>
>> I think a svn based plan would be nice, too. As it would be a bit more
>> official. Something like roadmap.txt in the main dir?
> I think it would be better to have it in a separate part of SVN, not
> as part of trunk (it's not intended for release)
> It could be under branches, or it could be top-level.
> Just not tags nor trunk please.
>
> Also there should be a single page for each idea.
I think it branches is not the right place, since I expect complete
branches there. So a top level would be more appropriate, but it still
feels wrong to me.
Maybe place (hide) it inside xdocs?
>
>> I would try to update the wiki page, but my (newly created) account
>> "fschumacher" is not allowed to change anything :)
> Should be able to now.
I have added the ideas to the page FutureReleases. They contain links to
pages where discussion on each idea can take place.
The list has not been updated since 2009, so there will be quite a few
things, that jmeter is capable of by now and can be removed.
Regards
Felix
>
>> Regards,
>> Felix
>>
>>>
>>> On 30 August 2015 at 07:34, Philippe Mouawad <ph...@gmail.com>
>>> wrote:
>>>> Bumping for sebb as he requested it in another thread.
>>>>
>>>>
>>>> On Saturday, January 31, 2015, Philippe Mouawad
>>>> <ph...@gmail.com>
>>>> wrote:
>>>>
>>>>> +1 for all your suggestions.
>>>>>
>>>>> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
>>>>> felix.schumacher@internetallee.de
>>>>> <javascript:_e(%7B%7D,'cvml','felix.schumacher@internetallee.de');>>
>>>>> wrote:
>>>>>
>>>>>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>>>>>>
>>>>>>> Hello,
>>>>>>> I think it would be a good idea to fix a roadmap for next releases of
>>>>>>> JMeter so that we can concentrate our work on prioritary features.
>>>>>>>
>>>>>>> My prioritary ideas are the following:
>>>>>>>
>>>>>>> - Rework architecture to be able to use a pool of threads instead
>>>>>>> of
>>>>>>> thread or use Reactor Pattern (
>>>>>>> http://reactor.github.io/docs/api/reactor/timer/
>>>>>>> SimpleHashWheelTimer.html
>>>>>>> )
>>>>>>>
>>>>>> Maybe we could/have to convert the test elements to take a context
>>>>>> instead of cloning them for every thread. I believe we can save a lot
>>>>>> of
>>>>>> memory that way. I think we have to do something in this respect.
>>>>>>
>>>>>> - Introduce Http Client async feature or at least use one
>>>>>> HttpClient
>>>>>>> for
>>>>>>> all threads
>>>>>>>
>>>>>> I think it would be nice to have parallel http requests for one thread
>>>>>> (simulated user) to be able to simulate the requests of a browser more
>>>>>> accurately.
>>>>>>
>>>>>> - Support Websocket and SPDY2 (bugzilla for those, but they depend
>>>>>> on
>>>>>>> first 2)
>>>>>>> - Create an Async listener + a pluggable one (to allow Graphite
>>>>>>> /JDBC
>>>>>>> plugins) , see https://issues.apache.org/
>>>>>>> bugzilla/show_bug.cgi?id=55932
>>>>>>
>>>>>>> . I made progress but didn't commit work yet
>>>>>>>
>>>>>> Done since then
>>>>
>>>>> - Fix known bugs in REDO/UNDO new feature
>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>>>>>>
>>>>>> Another thing I think we should consider is a StreamProcessor, which
>>>>>> can
>>>>>> be used to look/modify the results of a sampler as they happen, instead
>>>>>> of
>>>>>> a PostProcessor, which gets all the data after the sampler has got it.
>>>>>> That
>>>>>> would enable us for example to compute the md5 sum for large streaming
>>>>>> data, or validate that streaming data, without using too much memory.
>>>>>>
>>>>>> I would like to see more imap sampler possibilities, like quota,
>>>>>> status,
>>>>>> search to be able to put an imap server under load.
>>>>>>
>>>>>> There is a wiki page which holds a "roadmap", should we update our
>>>>>> ideas
>>>>>> there?
>>>>>>
>>>>> Yes good idea.
>>>>>
>>>>>> Regards
>>>>>> Felix
>>>>>>
>>>>>>
>>>>>>> I suggest everyone enhances this roadmap and we vote to decide on the
>>>>>>> priorities.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Cordialement.
>>>>> Philippe Mouawad.
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Cordialement.
>>>> Philippe Mouawad.
>>
Re: JMeter Roadmap for 2014/2015
Posted by sebb <se...@gmail.com>.
On 30 August 2015 at 12:07, Felix Schumacher
<fe...@internetallee.de> wrote:
> Am 30.08.2015 um 12:33 schrieb sebb:
>>
>> Thanks for the bump.
>>
>> As mentioned in the thread, it would be useful to have a Wiki page or
>> SVN document (or several) where the ideas can be fleshed out.
>> In particular, the architecture rework and shared samplers would have
>> a major impact on the design and 3rd party samplers, as well as being
>> a lot of work.
>>
>> I am always more wary about changes that affect the whole of JMeter
>> compared with new test elements.
>> This is because the knock-on effects are very difficult to forsee.
>> I think we tend to underestimate the amount of work needed to complete
>> a feature, for example Undo/Redo.
>> Optional addons are less of a risk, but of course still need
>> documentation, maintenance and user support.
>> This is why I have often been resistant to new features that are
>> relatively specialised.
>>
>> I won't comment on individual features here because the thread will
>> get impossible to follow.
>
> There is already a (very old) page with ideas to implement
> (https://wiki.apache.org/jmeter/FutureReleases) which could be a starting
> page to fetch up with the current state of jmeter.
>
> I think a svn based plan would be nice, too. As it would be a bit more
> official. Something like roadmap.txt in the main dir?
I think it would be better to have it in a separate part of SVN, not
as part of trunk (it's not intended for release)
It could be under branches, or it could be top-level.
Just not tags nor trunk please.
Also there should be a single page for each idea.
> I would try to update the wiki page, but my (newly created) account
> "fschumacher" is not allowed to change anything :)
Should be able to now.
> Regards,
> Felix
>
>>
>>
>> On 30 August 2015 at 07:34, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>>>
>>> Bumping for sebb as he requested it in another thread.
>>>
>>>
>>> On Saturday, January 31, 2015, Philippe Mouawad
>>> <ph...@gmail.com>
>>> wrote:
>>>
>>>> +1 for all your suggestions.
>>>>
>>>> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
>>>> felix.schumacher@internetallee.de
>>>> <javascript:_e(%7B%7D,'cvml','felix.schumacher@internetallee.de');>>
>>>> wrote:
>>>>
>>>>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>>>>>
>>>>>> Hello,
>>>>>> I think it would be a good idea to fix a roadmap for next releases of
>>>>>> JMeter so that we can concentrate our work on prioritary features.
>>>>>>
>>>>>> My prioritary ideas are the following:
>>>>>>
>>>>>> - Rework architecture to be able to use a pool of threads instead
>>>>>> of
>>>>>> thread or use Reactor Pattern (
>>>>>> http://reactor.github.io/docs/api/reactor/timer/
>>>>>> SimpleHashWheelTimer.html
>>>>>> )
>>>>>>
>>>>> Maybe we could/have to convert the test elements to take a context
>>>>> instead of cloning them for every thread. I believe we can save a lot
>>>>> of
>>>>> memory that way. I think we have to do something in this respect.
>>>>>
>>>>> - Introduce Http Client async feature or at least use one
>>>>> HttpClient
>>>>>>
>>>>>> for
>>>>>> all threads
>>>>>>
>>>>> I think it would be nice to have parallel http requests for one thread
>>>>> (simulated user) to be able to simulate the requests of a browser more
>>>>> accurately.
>>>>>
>>>>> - Support Websocket and SPDY2 (bugzilla for those, but they depend
>>>>> on
>>>>>>
>>>>>> first 2)
>>>>>> - Create an Async listener + a pluggable one (to allow Graphite
>>>>>> /JDBC
>>>>>> plugins) , see https://issues.apache.org/
>>>>>> bugzilla/show_bug.cgi?id=55932
>>>>>
>>>>>
>>>>>> . I made progress but didn't commit work yet
>>>>>>
>>>>> Done since then
>>>
>>>
>>>> - Fix known bugs in REDO/UNDO new feature
>>>>>>
>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>>>>>
>>>>> Another thing I think we should consider is a StreamProcessor, which
>>>>> can
>>>>> be used to look/modify the results of a sampler as they happen, instead
>>>>> of
>>>>> a PostProcessor, which gets all the data after the sampler has got it.
>>>>> That
>>>>> would enable us for example to compute the md5 sum for large streaming
>>>>> data, or validate that streaming data, without using too much memory.
>>>>>
>>>>> I would like to see more imap sampler possibilities, like quota,
>>>>> status,
>>>>> search to be able to put an imap server under load.
>>>>>
>>>>> There is a wiki page which holds a "roadmap", should we update our
>>>>> ideas
>>>>> there?
>>>>>
>>>> Yes good idea.
>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>
>>>>>> I suggest everyone enhances this roadmap and we vote to decide on the
>>>>>> priorities.
>>>>>>
>>>>>> Thoughts ?
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Cordialement.
>>>> Philippe Mouawad.
>>>>
>>>>
>>>>
>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>
>
Re: JMeter Roadmap for 2014/2015
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 30.08.2015 um 12:33 schrieb sebb:
> Thanks for the bump.
>
> As mentioned in the thread, it would be useful to have a Wiki page or
> SVN document (or several) where the ideas can be fleshed out.
> In particular, the architecture rework and shared samplers would have
> a major impact on the design and 3rd party samplers, as well as being
> a lot of work.
>
> I am always more wary about changes that affect the whole of JMeter
> compared with new test elements.
> This is because the knock-on effects are very difficult to forsee.
> I think we tend to underestimate the amount of work needed to complete
> a feature, for example Undo/Redo.
> Optional addons are less of a risk, but of course still need
> documentation, maintenance and user support.
> This is why I have often been resistant to new features that are
> relatively specialised.
>
> I won't comment on individual features here because the thread will
> get impossible to follow.
There is already a (very old) page with ideas to implement
(https://wiki.apache.org/jmeter/FutureReleases) which could be a
starting page to fetch up with the current state of jmeter.
I think a svn based plan would be nice, too. As it would be a bit more
official. Something like roadmap.txt in the main dir?
I would try to update the wiki page, but my (newly created) account
"fschumacher" is not allowed to change anything :)
Regards,
Felix
>
>
> On 30 August 2015 at 07:34, Philippe Mouawad <ph...@gmail.com> wrote:
>> Bumping for sebb as he requested it in another thread.
>>
>>
>> On Saturday, January 31, 2015, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>>
>>> +1 for all your suggestions.
>>>
>>> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
>>> felix.schumacher@internetallee.de
>>> <javascript:_e(%7B%7D,'cvml','felix.schumacher@internetallee.de');>>
>>> wrote:
>>>
>>>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>>>>
>>>>> Hello,
>>>>> I think it would be a good idea to fix a roadmap for next releases of
>>>>> JMeter so that we can concentrate our work on prioritary features.
>>>>>
>>>>> My prioritary ideas are the following:
>>>>>
>>>>> - Rework architecture to be able to use a pool of threads instead of
>>>>> thread or use Reactor Pattern (
>>>>> http://reactor.github.io/docs/api/reactor/timer/
>>>>> SimpleHashWheelTimer.html
>>>>> )
>>>>>
>>>> Maybe we could/have to convert the test elements to take a context
>>>> instead of cloning them for every thread. I believe we can save a lot of
>>>> memory that way. I think we have to do something in this respect.
>>>>
>>>> - Introduce Http Client async feature or at least use one HttpClient
>>>>> for
>>>>> all threads
>>>>>
>>>> I think it would be nice to have parallel http requests for one thread
>>>> (simulated user) to be able to simulate the requests of a browser more
>>>> accurately.
>>>>
>>>> - Support Websocket and SPDY2 (bugzilla for those, but they depend on
>>>>> first 2)
>>>>> - Create an Async listener + a pluggable one (to allow Graphite /JDBC
>>>>> plugins) , see https://issues.apache.org/
>>>>> bugzilla/show_bug.cgi?id=55932
>>>>
>>>>> . I made progress but didn't commit work yet
>>>>>
>>>> Done since then
>>
>>> - Fix known bugs in REDO/UNDO new feature
>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>>>>
>>>> Another thing I think we should consider is a StreamProcessor, which can
>>>> be used to look/modify the results of a sampler as they happen, instead of
>>>> a PostProcessor, which gets all the data after the sampler has got it. That
>>>> would enable us for example to compute the md5 sum for large streaming
>>>> data, or validate that streaming data, without using too much memory.
>>>>
>>>> I would like to see more imap sampler possibilities, like quota, status,
>>>> search to be able to put an imap server under load.
>>>>
>>>> There is a wiki page which holds a "roadmap", should we update our ideas
>>>> there?
>>>>
>>> Yes good idea.
>>>
>>>> Regards
>>>> Felix
>>>>
>>>>
>>>>> I suggest everyone enhances this roadmap and we vote to decide on the
>>>>> priorities.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>>
>>>
>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>>>
>>>
>>>
>> --
>> Cordialement.
>> Philippe Mouawad.
Re: JMeter Roadmap for 2014/2015
Posted by sebb <se...@gmail.com>.
Thanks for the bump.
As mentioned in the thread, it would be useful to have a Wiki page or
SVN document (or several) where the ideas can be fleshed out.
In particular, the architecture rework and shared samplers would have
a major impact on the design and 3rd party samplers, as well as being
a lot of work.
I am always more wary about changes that affect the whole of JMeter
compared with new test elements.
This is because the knock-on effects are very difficult to forsee.
I think we tend to underestimate the amount of work needed to complete
a feature, for example Undo/Redo.
Optional addons are less of a risk, but of course still need
documentation, maintenance and user support.
This is why I have often been resistant to new features that are
relatively specialised.
I won't comment on individual features here because the thread will
get impossible to follow.
On 30 August 2015 at 07:34, Philippe Mouawad <ph...@gmail.com> wrote:
> Bumping for sebb as he requested it in another thread.
>
>
> On Saturday, January 31, 2015, Philippe Mouawad <ph...@gmail.com>
> wrote:
>
>> +1 for all your suggestions.
>>
>> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
>> felix.schumacher@internetallee.de
>> <javascript:_e(%7B%7D,'cvml','felix.schumacher@internetallee.de');>>
>> wrote:
>>
>>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>>>
>>>> Hello,
>>>> I think it would be a good idea to fix a roadmap for next releases of
>>>> JMeter so that we can concentrate our work on prioritary features.
>>>>
>>>> My prioritary ideas are the following:
>>>>
>>>> - Rework architecture to be able to use a pool of threads instead of
>>>> thread or use Reactor Pattern (
>>>> http://reactor.github.io/docs/api/reactor/timer/
>>>> SimpleHashWheelTimer.html
>>>> )
>>>>
>>> Maybe we could/have to convert the test elements to take a context
>>> instead of cloning them for every thread. I believe we can save a lot of
>>> memory that way. I think we have to do something in this respect.
>>>
>>> - Introduce Http Client async feature or at least use one HttpClient
>>>> for
>>>> all threads
>>>>
>>> I think it would be nice to have parallel http requests for one thread
>>> (simulated user) to be able to simulate the requests of a browser more
>>> accurately.
>>>
>>> - Support Websocket and SPDY2 (bugzilla for those, but they depend on
>>>> first 2)
>>>> - Create an Async listener + a pluggable one (to allow Graphite /JDBC
>>>> plugins) , see https://issues.apache.org/
>>>> bugzilla/show_bug.cgi?id=55932
>>>
>>>
>>>> . I made progress but didn't commit work yet
>>>>
>>> Done since then
>
>
>> - Fix known bugs in REDO/UNDO new feature
>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>>>
>>> Another thing I think we should consider is a StreamProcessor, which can
>>> be used to look/modify the results of a sampler as they happen, instead of
>>> a PostProcessor, which gets all the data after the sampler has got it. That
>>> would enable us for example to compute the md5 sum for large streaming
>>> data, or validate that streaming data, without using too much memory.
>>>
>>> I would like to see more imap sampler possibilities, like quota, status,
>>> search to be able to put an imap server under load.
>>>
>>> There is a wiki page which holds a "roadmap", should we update our ideas
>>> there?
>>>
>> Yes good idea.
>>
>>>
>>> Regards
>>> Felix
>>>
>>>
>>>> I suggest everyone enhances this roadmap and we vote to decide on the
>>>> priorities.
>>>>
>>>> Thoughts ?
>>>>
>>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: JMeter Roadmap for 2014/2015
Posted by Philippe Mouawad <ph...@gmail.com>.
Bumping for sebb as he requested it in another thread.
On Saturday, January 31, 2015, Philippe Mouawad <ph...@gmail.com>
wrote:
> +1 for all your suggestions.
>
> On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
> felix.schumacher@internetallee.de
> <javascript:_e(%7B%7D,'cvml','felix.schumacher@internetallee.de');>>
> wrote:
>
>> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>>
>>> Hello,
>>> I think it would be a good idea to fix a roadmap for next releases of
>>> JMeter so that we can concentrate our work on prioritary features.
>>>
>>> My prioritary ideas are the following:
>>>
>>> - Rework architecture to be able to use a pool of threads instead of
>>> thread or use Reactor Pattern (
>>> http://reactor.github.io/docs/api/reactor/timer/
>>> SimpleHashWheelTimer.html
>>> )
>>>
>> Maybe we could/have to convert the test elements to take a context
>> instead of cloning them for every thread. I believe we can save a lot of
>> memory that way. I think we have to do something in this respect.
>>
>> - Introduce Http Client async feature or at least use one HttpClient
>>> for
>>> all threads
>>>
>> I think it would be nice to have parallel http requests for one thread
>> (simulated user) to be able to simulate the requests of a browser more
>> accurately.
>>
>> - Support Websocket and SPDY2 (bugzilla for those, but they depend on
>>> first 2)
>>> - Create an Async listener + a pluggable one (to allow Graphite /JDBC
>>> plugins) , see https://issues.apache.org/
>>> bugzilla/show_bug.cgi?id=55932
>>
>>
>>> . I made progress but didn't commit work yet
>>>
>> Done since then
> - Fix known bugs in REDO/UNDO new feature
>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>>
>> Another thing I think we should consider is a StreamProcessor, which can
>> be used to look/modify the results of a sampler as they happen, instead of
>> a PostProcessor, which gets all the data after the sampler has got it. That
>> would enable us for example to compute the md5 sum for large streaming
>> data, or validate that streaming data, without using too much memory.
>>
>> I would like to see more imap sampler possibilities, like quota, status,
>> search to be able to put an imap server under load.
>>
>> There is a wiki page which holds a "roadmap", should we update our ideas
>> there?
>>
> Yes good idea.
>
>>
>> Regards
>> Felix
>>
>>
>>> I suggest everyone enhances this roadmap and we vote to decide on the
>>> priorities.
>>>
>>> Thoughts ?
>>>
>>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: JMeter Roadmap for 2014/2015
Posted by Philippe Mouawad <ph...@gmail.com>.
+1 for all your suggestions.
On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
felix.schumacher@internetallee.de> wrote:
> Am 14.10.2014 um 21:46 schrieb Philippe Mouawad:
>
>> Hello,
>> I think it would be a good idea to fix a roadmap for next releases of
>> JMeter so that we can concentrate our work on prioritary features.
>>
>> My prioritary ideas are the following:
>>
>> - Rework architecture to be able to use a pool of threads instead of
>> thread or use Reactor Pattern (
>> http://reactor.github.io/docs/api/reactor/timer/
>> SimpleHashWheelTimer.html
>> )
>>
> Maybe we could/have to convert the test elements to take a context instead
> of cloning them for every thread. I believe we can save a lot of memory
> that way. I think we have to do something in this respect.
>
> - Introduce Http Client async feature or at least use one HttpClient
>> for
>> all threads
>>
> I think it would be nice to have parallel http requests for one thread
> (simulated user) to be able to simulate the requests of a browser more
> accurately.
>
> - Support Websocket and SPDY2 (bugzilla for those, but they depend on
>> first 2)
>> - Create an Async listener + a pluggable one (to allow Graphite /JDBC
>> plugins) , see https://issues.apache.org/
>> bugzilla/show_bug.cgi?id=55932
>> . I made progress but didn't commit work yet
>> - Fix known bugs in REDO/UNDO new feature
>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57043
>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57039
>> - https://issues.apache.org/bugzilla/show_bug.cgi?id=57040
>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53540
>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53833
>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53628
>> - Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=55597
>>
> Another thing I think we should consider is a StreamProcessor, which can
> be used to look/modify the results of a sampler as they happen, instead of
> a PostProcessor, which gets all the data after the sampler has got it. That
> would enable us for example to compute the md5 sum for large streaming
> data, or validate that streaming data, without using too much memory.
>
> I would like to see more imap sampler possibilities, like quota, status,
> search to be able to put an imap server under load.
>
> There is a wiki page which holds a "roadmap", should we update our ideas
> there?
>
Yes good idea.
>
> Regards
> Felix
>
>
>> I suggest everyone enhances this roadmap and we vote to decide on the
>> priorities.
>>
>> Thoughts ?
>>
>>
>
--
Cordialement.
Philippe Mouawad.