Testing Openfire with Grinder (BOSH load testing)

Question

I have been trying to test openfire server for Load testing over BOSH but I have been getting the following error after few minutes of run.

1)

11/4/11 3:49:33 PM (thread 3 run 0 test 601): Aborted run due to Java exception calling TestRunner

Java exception calling TestRunner

    File "D:\grinder\projects\loadtest\bin\..\tests\..\tests\one2one.py", line 144, in changePresence

    File "D:\grinder\projects\loadtest\bin\..\tests\..\tests\one2one.py", line 208, in __call__

Caused by: java.net.BindException: Address already in use: connect

2) I have also been getting 404 Invalid SID errors.

Initially I had set up openfire on Windows 2003 Server but later I set it up on ubuntu 11.10 (RAM 2.0 GiB Intel Core Duo T2400 @ 1.83GHz)

1) Firstly, I ran php curl fetch script to add users to using the userservices plugin to add something around 10,000 uses (during which I got a lot of blank responses , so may be this is related to the problem but I will not focus on this misbehaviour now)

2) But I needed to test this for 400 users so i had the following grinder.properties set:

grinder.processes=4

grinder.threads=100

grinder.runs=1



grinder.consoleHost=192.168.1.205

grinder.consolePort=6372



grinder.logDirectory=../logs

grinder.numberOfOldLogs=0

grinder.jvm.arguments=-Dpython.cachedir=../tmp



grinder.script=../tests/one2one.py

(this strangely ended up starting only 103 concurrent users)

(I have tried testing this using one agent)

3) I did a bit of a research and found that I could configure openfire for bosh; so i added the following system.properties

xmpp.httpbind.client.idle 360

xmpp.httpbind.client.requests.max 400

badly need help!!!!! anyone has an insight about how can i resolve this?

Answer 1

The "Address already in use" problem is odd. You may want to try with

grinder.processes=1
grinder.threads=400

As far as only seeing 103 concurrent users, how long does it take for a single of your grinder runs to execute? My thinking is the earliest threads the JVM executes are completing before the final threads have a chance to fully initialize and do work. If you try this:

grinder.runs=100

You will be more likely to achieve the full level of concurrency you are looking for.