jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JMeter Roadmap for 2014/2015
Date Sun, 30 Aug 2015 11:47:38 GMT
On 30 August 2015 at 12:07, Felix Schumacher
<felix.schumacher@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 <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