Am 30.08.2015 um 13:47 schrieb sebb:
On 30 August 2015 at 12:07, Felix Schumacher
<[email protected]> 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 <[email protected]>
wrote:
Bumping for sebb as he requested it in another thread.
On Saturday, January 31, 2015, Philippe Mouawad
<[email protected]>
wrote:
+1 for all your suggestions.
On Sat, Jan 31, 2015 at 2:19 PM, Felix Schumacher <
[email protected]
<javascript:_e(%7B%7D,'cvml','[email protected]');>>
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.
