jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: JMeter Roadmap for 2014/2015
Date Sun, 30 Aug 2015 11:07:00 GMT
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 <philippe.mouawad@gmail.com> wrote:
>> Bumping for sebb as he requested it in another thread.
>>
>>
>> On Saturday, January 31, 2015, Philippe Mouawad <philippe.mouawad@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.


Mime
View raw message