blob: 0b1d6d4f9080069fe916dd80b6c4c8040e81b4f5 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
Running Performance Tests
-------------------------
This performance test suite contains a number of tests.
- Service request-reply
- Ping-Pong
- Headers
Service request-reply
---------------------
Description:
This is the simplest test to ensure everything is working. This involves
one client that is known as a "service provider" and it listens on a
well-known queue for requests. Another client, known as the "service requester"
creates a private (temporary) response queue, creates a message with the
private response queue set as the "reply to" field and then publishes the
message to the well known service queue. The test allows you to time how long
it takes to send messages and receive the response back. It also allows varying
of the message size.
QuickRun:
./serviceRequestReply-QuickTest.sh <brokerdetails> <number of messages>
This provides a quick test to run everything against a running broker. Simply specify broker and number of messages to run.
Detailed Run:
You must start the service provider first:
serviceProvidingClient.sh <brokerdetails> [<P[ersistent]|N[onPersistent]> <T[ransacted]|N[onTransacted]>] [selector]
where Brokerdetails is the connection information to the broker you are running on; e.g. localhost or localhost:5670 or tcp://10.10.10.10:5677.
By default Non Persistent, Non Transaction messages are used in the response. A selector may also be specified.
To run the service requester:
serviceRequestingClient.sh <Brokerdetails> <Number of Messages> [<Message Size>] [<P[ersistent]|N[onPersistent]> <T[ransacted]|N[onTransacted]>]
This requests the <number of messages> of a <Message Size (default 4096 bytes>. By default the connection is Non Persistent and Non Transactional.
After receiving all the messages the client outputs the rate it achieved.
Ping-Pong
---------
Headers
-------
A more realistic test is the "headers test", which tests the
performance of routing messages based on message headers to a
configurable number of clients (e.g. 50). A publisher sends 10000
messages to each client and waits to receive a message from each
client when it has received all the messages.
You run the listener processes first:
run_many.sh 10 header "headersListener.sh -host 10.0.0.1 -port 5672"
In this command, the first argument means start 10 processes, the
second is just a name use in the log files generated and the third
argument is the command to run. In this case it runs another shell
script but it could be anything.
Then run the publisher process:
headersPublisher.sh -host 10.0.0.1 -port 5672 10000 10
The last two arguments are: the number of messages to send to each
client, and the number of clients.
Note that before starting the publisher you should wait about 30
seconds to ensure all the clients are registered with the broker (you
can see this from the broker output). Otherwise the numbers will be
slightly skewed.
A third useful test, which can easily be ported to other JMS
implementations is the "topic test". It does the same as the headers
test but using a standard topic (e.g. pub sub).
To run the listeners:
run_many.sh 10 topic "topicListener.sh -host 10.0.0.1 -port 5672"
and to run the publisher:
topicPublisher.sh -host 10.0.0.1 -port 5672 -clients 10 -messages 10000
|
