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 14:08:01 GMT
On 30 August 2015 at 14:59, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
> Am 30.08.2015 um 13:47 schrieb sebb:
>>
>> 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 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
>>>> <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