JGroups Performance Test from official site

« JGroups and JGroup... | Blog首页 | 设计模式资料 »

2006/05/04

结果大于 10k messages/ second ，这样的性能感觉不错。 (每个 message 1k)

并且JGroups 已经支持了 java nio ，这样当节点再增加时不会因为 Thread 的增多而导致性能下降。

测试结果如下：

The JGroups PerfTests (http://wiki.jboss.org/wiki/Wiki.jsp?page=PerfTests) measures the time to send N messages to all members of a group. It computes messages/sec and throughput for each member in the group. Each machine was configured to be a sender and receive every message sent. Each machine sends 1,000,000 messages.

Test Run #

Number of messages read per second

1

13402

2

13155

3

13344

4

13107

Test results using TCP

Test Run #

Number of messages read per second

1

13490

2

13462

3

13476

4

13440

A 20 million message test was also run to ensure that there are no memory leaks.

Test Run #	Number of messages read per second
1	13402
2	13155
3	13344
4	13107

Test Run #	Number of messages read per second
1	13490
2	13462
3	13476
4	13440

测试环境：

Configuring Reader, Writer and Processor Threads

TCP_NIO has configuration settings for the number of reader, writer and processor threads. Generally, setting the number of threads to a smaller number is better than a larger number. As a starting point, try:

reader_threads = 8 * number of CPUs

writer_threads = 8 * number of CPUs

processor_threads = 8 * number of CPUs

processor_minThreads = 8 * number of CPUs

processor_maxThreads = 8 * number of CPUs

processor_keepAlivetime = -1

processor_queueSize = 100

The reader threads read incoming requests and hand the request off to the processor threads to be handled. The processor threads may be disabled (processor_maxThreads is set to zero) so that the incoming requests are handled in the reader threads.

If processor_minThreads is less than processor_maxThreads, new threads will be created to process requests, if and only if, the processor internal queue has processor_queueSize entries in it. This occurs at the time that the next request needs to be processed.

If the internal queue is full and processor_maxThreads threads are busy, the reader thread will block until one of the processor threads completes its work.

Testing environment

Cluster: 4 Dell Optiplex GX260 machines

CPU: Three Intel Pentium 4 2.26GHz and one Pentium 4 2GHz

Memory: 1GB

OS: SUSE Linux Enterprise Server 9 (kernel: 2.6.5)

Switch: 100Mega bit

JGroups configuration file

<config>

<TCP_NIO bind_addr="164.99.218.115" recv_buf_size="20000000" send_buf_size="640000"

loopback="false" discard_incompatible_packets="true" max_bundle_size="64000"

max_bundle_timeout="30" use_incoming_packet_handler="true"

use_outgoing_packet_handler="true" down_thread="false" up_thread="false"

enable_bundling="true" start_port="7800" use_send_queues="false"

sock_conn_timeout="300" skip_suspected_members="true"/>

<MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8"

bind_addr="164.99.218.115" down_thread="false" up_thread="false"/>

<FD_SOCK down_thread="false" up_thread="false"/>

<pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="10"

retransmit_timeout="100,200,300,600,1200,2400,4800" down_thread="false" up_thread="false"

discard_delivered_msgs="true"/>

<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false"

up_thread="false" max_bytes="400000"/>

<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" up_thread="false"

join_retry_timeout="2000" shun="true"/>

<FC max_credits="2000000" down_thread="false" up_thread="false" min_threshold="0.10"

max_block_time="1000"/>

</config>

Test 'config.txt' file

num_msgs=1000000 msg_size=1000 num_members=4 num_senders=4

Java

Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)

Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)”