I'm also interested in english version
On Wednesday, August 31, 2016, Antonio Gomes Rodrigues
wrote:
> I am interested by English slides if you have time to translate it :-)
>
> 2016-08-31 14:35 GMT+02:00 Vladimir Sitnikov >:
>
> > Antonio>Is the slides will be available?
> >
> > The talk will
On Wednesday, August 31, 2016, Epp, Jeremiah W (Contractor)
wrote:
> > -Original Message-
> > From: Vladimir Sitnikov [mailto:sitnikov.vladi...@gmail.com
> ]
> > Sent: Wednesday, August 31, 2016 4:24 AM
> > To: dev@jmeter.apache.org
> > Subject: Test plan warnings
> >
> > 1) A proper way
> -Original Message-
> From: Vladimir Sitnikov [mailto:sitnikov.vladi...@gmail.com]
> Sent: Wednesday, August 31, 2016 4:24 AM
> To: dev@jmeter.apache.org
> Subject: Test plan warnings
>
> 1) A proper way to place inter-page timers is to wrap the timer into some
> kind of "test action". So
I am interested by English slides if you have time to translate it :-)
2016-08-31 14:35 GMT+02:00 Vladimir Sitnikov :
> Antonio>Is the slides will be available?
>
> The talk will be in Russian, so I've got draft slides in Russian.
>
> I might create English variation if there's a demand.
>
>
> Vl
Antonio>Is the slides will be available?
The talk will be in Russian, so I've got draft slides in Russian.
I might create English variation if there's a demand.
Vladimir
Hi Vladimir,
No JMeter hangout / load test conference planned for me
Arranging a hangout session could be great but, in my opinion, but they
must be different from those organized by Blazemeter/etc.
I think we need to add to JMeter site/wiki a list of previous and planned
conference
And "bravo
I find the idea nice.
the reporting could be similar to eclipse problems view at the bottom.
This way if user is not interested he can remove the view. Or we can pake
the view appear only on demand.
I think it could be built in a way that makes checks pluggable.
On Wednesday, August 31, 2016,
Hi Andrei,
Existence of your plugins manager(which is a great idea that should have
been in Core) must not mean core Jmeter should not be enhanced.
Plugins can be of any quality, having features in core guarantees it.
Regards
On Wednesday, August 31, 2016, Andrey Pokhilko wrote:
> That thread
Hi Vladimir,
As you can read I just tried to provide an answer to your question.
I don't think there was a patch right ?
You can see I asked for a bugzilla and an attached patch.
Anyway, please provide a patch so that we can review it.
I am very interested if it is a better solution than CTT.
Re
Andrey>That thread was one year ago.
JMeterPlugins discussion
https://groups.google.com/forum/#!msg/jmeter-plugins/K8I6LIRwYjM/kWteXor28kQJ
took
place more than three years ago.
2013/04/04 to be exact.
Vladimir
Philippe>Are you sure you submitted it to JMeter ?
I am quite sure.
Here's the thread:
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201502.mbox/%3CCAB=Je-GON1QUxAD6nnzMLA0wh9JMpk8nh=y8uylihfg8mao...@mail.gmail.com%3E
Here's your response
http://mail-archives.apache.org/mod_mbox/jmeter-dev
That thread was one year ago. Today, there is Plugins Manager that
allows you to maintain your plugin under your GitHub account and use
Plugins Manager as a way to distribute your plugin for audience.
Andrey Pokhilko
On 08/31/2016 01:20 PM, Philippe Mouawad wrote:
> On Wednesday, August 31, 2016,
On Wednesday, August 31, 2016, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> UBIK>because you mentioned in the bugzilla CTT
>
> I try to protect JMeter end-users from culprits like "when using adjust
> timers CTT produces completely wrong load rate". I do not suggest to
> discuss CTT
sebb>I think it's far more important to ensure that the features ... and
well documented.
Note: there are certain peculiarities that are very unexpected by the
typical user.
Of course doing some RTFM solves some problems, however I still think
having a spell checker that allows false positives is
Hi
I think it could be usefull for performance warning
Antonio
2016-08-31 11:20 GMT+02:00 Milamber :
>
>
> On 31/08/2016 10:11, sebb wrote:
>
>> I think it's far more important to ensure that the features which are
>> added to JMeter are genuinely useful and well documented.
>>
>
> +1
>
>
>
On 31 August 2016 at 10:09, Vladimir Sitnikov
wrote:
> Andrey>That's why I used "label prefix" approach to visually
> group plugins of "jp@gc"
> Andrey>It serves the purpose of grouping without
> introducing new menu levels.
>
> jp@gc makes it hard to read.
+1
> Nothing personal, but I'm always re
On 31/08/2016 10:11, sebb wrote:
I think it's far more important to ensure that the features which are
added to JMeter are genuinely useful and well documented.
+1
Andrey> I was using a same kind of way but it works only for conscious
users in my case - that's why I'm looking for a more user friendly approach
Andrey, Vladimir> at least only one sub level may be enough
Vincent
2016-08-31 11:09 GMT+02:00 Vladimir Sitnikov :
> Andrey>That's why I used "label
On 31 August 2016 at 09:23, Vladimir Sitnikov
wrote:
> Hi,
>
> As far as I understand, JMeter UI lacks feedback for "error prone"
> configurations. It would be so much better if JMeter would have "spell
> checker" integrated, so it warned on "bad test plan patterns".
>
Not strictly true.
The GUI
Andrey>That's why I used "label prefix" approach to visually
group plugins of "jp@gc"
Andrey>It serves the purpose of grouping without
introducing new menu levels.
jp@gc makes it hard to read.
Nothing personal, but I'm always reading jp@gc as something like *(╯°□°）╯︵
┻━┻*
The idea of enabling plu
Hi,
My opinion, the deep nested popup menus is bad UX. It's tedious to find
elements in them. That's why I used "label prefix" approach to visually
group plugins of "jp@gc". It serves the purpose of grouping without
introducing new menu levels.
Andrey Pokhilko
On 08/31/2016 11:42 AM, Vincent HER
Accordingly to my own usecases, I didn't consider finding elements by this
way, but why not...
My purpose is more about grouping elements around protocol related sets or
plugin related.
Considering a getSubMenuCategories() method like the getMenuCategories()
does for config/samplers/..., it could
Vincent>find the related
Vincent>config/sampler/... elements into the native ones.
Just in case: do you mean "quick search" makes sense?
For instance: allow whatever grouping that makes sense, however enable
quick search of the elements when user opens menu and starts typing.
I think a plugin sho
Hi,
First, thanks to all of you for your work on JMeter.
Maybe I'm re-opening a discussion thread about the need of submenus to
handle JMeter elements but when several plugins are developed around
JMeter, it is difficult to manage, organise, find the related
config/sampler/... elements into the n
UBIK>because you mentioned in the bugzilla CTT
I try to protect JMeter end-users from culprits like "when using adjust
timers CTT produces completely wrong load rate". I do not suggest to
discuss CTT drawbacks here.
UBIK>CTT has use cases but does not fit here due to variable pauses I think.
As
Hi,
As far as I understand, JMeter UI lacks feedback for "error prone"
configurations. It would be so much better if JMeter would have "spell
checker" integrated, so it warned on "bad test plan patterns".
Was there a discussion/plan to implement that?
I'm sure lack of that checker makes it very h
On Wed, Aug 31, 2016 at 10:04 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> UBIK>The issue with CTT is that it tries to match the throughput but always
> exceeds it before slowing down, and if CTT is combined with variable pauses
> UBIK>, it becomes very hard for CTT to adjust the
UBIK>The issue with CTT is that it tries to match the throughput but always
exceeds it before slowing down, and if CTT is combined with variable pauses
UBIK>, it becomes very hard for CTT to adjust the pauses to reach the
Throughput..
If CTT has issues, why don't we just fix CTT then?
Do you mean
On Wed, Aug 31, 2016 at 9:17 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >As you read, the proposed solution (add a new field to timers) handles
> also
> the Ajax case.
>
> That is true.
> However it would likely to require user to walk over test plan and flip
> switches "adjust
Hi,
I wonder if there's a planned JMeter hangout / load test conference.
Do you think arranging a hangout session makes sense?
JFYI: My JMeter-related talk is accepted to http://heisenbug.ru/en/ conference:
http://heisenbug.ru/en/talks/shopping_list_what_you_need_to_remember_when_running_jmeter_
Hi
My answers inline below
2016-08-31 1:11 GMT+02:00 harry_no_spot <13651877...@163.com>:
> In my opinion. in LR it's a goodlooking feature but not a very userfu
> feature.
>
All the Loadrunner experts I know (inluding me) use this feature in
LoadRunner
> This feathure has no big use in practi
Hi
In Loadrunner, the feature (if my remember are good) only modify the think
time of the lr_think_time() function used in the script
Antonio
2016-08-31 9:17 GMT+02:00 Vladimir Sitnikov :
> >As you read, the proposed solution (add a new field to timers) handles
> also
> the Ajax case.
>
> That
>As you read, the proposed solution (add a new field to timers) handles also
the Ajax case.
That is true.
However it would likely to require user to walk over test plan and flip
switches "adjust or not" manually. That's a pity.
That would open one more pitfall of "blind timer adjustment would giv
On Wed, Aug 31, 2016 at 8:58 AM, Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >Yes , but this case is already edgy in JMeter as there is no concept of
> parallel request
>
> Note:
> 1) page...ajax delay can be used even without parallel requests
> 2) I expect "parallel request" featur
34 matches
Mail list logo
