Hi,
I am using JMeter(2.4) for doing the loading testing of XMPP server and my test
plan is configured as following:
- Test plan
- Thread group
- Loop Controller
- Java Request
- Generate Summary Results
- Constant timer/Constant throughput timer
- CSV Data Set
It seems you are clicking on the md5 link.
Instead, click on
http://mirrors.enquira.co.uk/apache//jakarta/jmeter/binaries/jakarta-jmeter-2.5.zip
2.5.zip
--
View this message in context:
Thank you, Oliver and Deepak.
@Deepak, there are many archive refrences, could you please point me to the
appropriate mail archive for this discussion?
Thank you very much!
-Joy
On Fri, Sep 9, 2011 at 9:46 PM, Deepak Shetty shet...@gmail.com wrote:
1. Do I need to record .jpg, .css, .js as part
Or better yet, think about your own particular situation:
Are you testing a public facing site or something internal?
Are you using a CDN?
Are you using content acceleration of any kind?
Where and what type of caching is in place?
At what point are you injecting load? Directly to the servers?
Perhaps there is a workaround for this, but I have identified a small flaw
in how JMeter is running threads.
Assume for a second that I have a test where I want to run a 100
simultaneous users through a procedure. I'd like the test to start and
finish running 100 simultaneous threads.
The way
On 12 September 2011 20:02, Robin D. Wilson rwils...@gmail.com wrote:
Perhaps there is a workaround for this, but I have identified a small flaw
in how JMeter is running threads.
Assume for a second that I have a test where I want to run a 100
simultaneous users through a procedure. I'd like
Could you use a synchronizing timer to insure your threads run more
consistently? I find them to be underrated, and they're worth taking a look
at if you haven't yet.
--
Bruce Ide
flyingrhenqu...@gmail.com
On 12 September 2011 20:15, Bruce Ide flyingrhenqu...@gmail.com wrote:
Could you use a synchronizing timer to insure your threads run more
consistently? I find them to be underrated, and they're worth taking a look
at if you haven't yet.
But that may make the test unrealistic - are the 100
Another idea would be to simply force stop the test using a Test
Action Sampler when any thread finishes its 1,000 iteration. This
could also help to prove if their is some sort of thread scheduling
problem here. For instance, if a single thread hits 1,000 and the
other threads are at their 30th
The simple answer is you would never do that. You will always have a
ramp-up and a ramp-down. You should exclude these phases in your
calculations if you need the values under load only. Even if you thread
issue were fixed, how would you deal with differing response times? They
still affect your
I have run up to three concurrent meter instances on one Linux VM with one
CPU and 2GB ram without ever having issues (last 6 years). I don't use the
Jmeter built in vertical scaling mechanism but start them timed through
shell scripts.
As for the changes to the OS you'll need to up your
The objective of the test is to see what the system performs like when there
are 100 concurrent requests going on... So long as we keep it at 100,
everything is fine. When I run 1 iterations (100 per thread), I see that
about 9400-9600 into the run, my thread count begins to drop off - until I
See below.
On 13/09/11 8:46 AM, Robin D. Wilson rwils...@gmail.com wrote:
The objective of the test is to see what the system performs like when
there
are 100 concurrent requests going on... So long as we keep it at 100,
everything is fine. When I run 1 iterations (100 per thread), I see
I am doing a baseline, and I am trying to repeat the same test... As I said,
it is only a 'small' flaw - nothing serious.
That being said, it is also reflecting a perspective on testing that is
perhaps different than yours. When I look at the results, I'd like them to
mean something, and I'm
Thanks guys, this is really useful stuff. I'm still being impressed by what
can be done with this tool.
I'm play with this over the next few days and report back.
-
http://www.http503.com/
--
View this message in context:
Hello,
Thanks for your suggestion. I kind of understood now where i went wrong.
While recording, in the Grouping drop down in HTTP Proxy Server, I selected
Do not group samplers. Thus each and every internal request was getting
recorded and then executed in sequence which was time consuming. Now
Well I did some more testing and I have to say that I'm still confused. All
I can figure is that I am misunderstanding how the constant throughput timer
works.
I was able to configure the throughput timer to get the same results as I
did without it (6000 req/sec) but I had to set the total
17 matches
Mail list logo
