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 13:59:41 GMT
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.

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 <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