Hi,

I finally found the problem, and of course it didn't have anything to do with jmeter :) The problem was that the computer I was running my apache server on had ip connection tracking enabled. It has an upper limit on how many connections it can track, and I exceeded that for some reason when I used two jmeter-servers. The strange thing is that I never saw the problem when I run one jmeter-server, even if I managed to load the server just as much as I did with two?

You may find the upper limit here:

cat /proc/sys/net/ipv4/ip_conntrack_max

I just turned the ip connection tracking off, and the problem disappeared. The ip_conntrack was built as a module on my system so I turned it off by removing the ip_conntrack.o file.

The reason why I didn't find this problem earlier is that I don't have root privileges on my machines, so I had to get hold of a person who has. And after having a look in the messages log file, the problem was more obvious.

Thank you for all your help!

//Erik



On 20/03/06, sebb wrote:


On 20/03/06, Erik Lindegren <[EMAIL PROTECTED]> wrote:

On 20/03/06, sebb wrote:

On 20/03/06, Erik Lindegren <[EMAIL PROTECTED]> wrote:
I have a strange problem with jmeter at the moment.
I'm trying to overload an apache  server on my local network.
I'm using 3 computers: one for the apache server, and the remaining
two for running remote jmeter servers.


When I've been running my test for about 40-50s both of the jmeter
servers stop sending http-requests to the apache server.After about
30-40s the jmeter servers start sending requests again, but after a
while they go down again, and so it continues.

Any messages in the jmeter.log files?
There are no messages in the log files indicating that something is
wrong. I've also looked in the apache error_log but nothing there
either.

Anything in the console window?
JMeter tries to trap and log exceptions, but some may slip past...


The testplan I'm using is as follows:
One thread group with 80 threads that should run forever
       An HTTP Request to a very small html page (52-bytes)
       Constant timer (300 ms)

And I run this test on two jmeter-servers, and the apache server
manages to serve about 500-550 requests per second. When the server
has been up for 66 s, one or both of the jmeter-servers stop sending
requests.
The same problem occur if I decrease the number of threads, but it
then takes longer time before the jmeter-servers stop sending requests.

Sounds like it may be temporary resource exhaustion.

Are you using Keep-Alive?

Are you sure that JMeter stops sending, or could it be that the server
stops responding?

The difference should show up in the response times.

The cpu and memory load on each machine are not heavy at all. The
local network is 100MBit/s so I don't think that might be the problem
either.



First I thought the problem was with the jmeter test plan, that it
was too cpu-consuming, but I setup a much more simple test plan and
the same problem still occured. As soon as I used both jmeter-
servers, they stopped sending requests after a while. When I use one
jmeter-server at the time, I have never gotten this problem.

Have anyone any idea of what the problem might be?
I would be very thankful for any help at all!

Just one more thing, when a jmeter test thread sends a http- request,
does it wait for an ACK before sending a new request?

HTTP is a request response protocol.

JMeter sends the request and waits for the response before continuing
to process any further requests in the same thread.

All JMeter samplers are request-response samplers.


//Erik





------------------------------------------------------------------- --
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: jmeter-user- [EMAIL PROTECTED]



-------------------------------------------------------------------- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to