| Author |
Message |
|
| Guest |
 Posted: Wed Apr 09, 2008 10:56 am |
 |
|
|
Guest
|
Hi,
we have done some stress tests of rabbitmq. Our main goal was the ~10K
messages per second and maximum cpu & ram usage. Two servers with equal
configuration listed below were used for this task.
Intel SR1500AL:
Intel S5000PAL MB, 2 Quad Core Xeon 5345 2,33Ghz, 4Gb FB RAM :
$ /usr/sbin/prtdiag
System Configuration: Intel S5000PAL
BIOS Configuration: Intel Corporation S5000.86B.10.00.0085.112920071426
11/29/2007
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)
==== Processor Sockets ====================================
Version Location Tag
-------------------------------- --------------------------
Intel(R) Xeon(R) CPU E5345 @ 2.33GHz CPU1
Intel(R) Xeon(R) CPU E5345 @ 2.33GHz CPU2
==== Memory Device Sockets ================================
Type Status Set Device Locator Bank Locator
------- ------ --- ------------------- --------------------
Unknown in use 1 ONBOARD DIMM_A1 Channel A
Unknown empty 2 ONBOARD DIMM_A2 Channel A
Unknown in use 1 ONBOARD DIMM_B1 Channel B
Unknown empty 2 ONBOARD DIMM_B2 Channel B
Unknown in use 5 ONBOARD DIMM_C1 Channel C
Unknown empty 6 ONBOARD DIMM_C2 Channel C
Unknown in use 5 ONBOARD DIMM_D1 Channel D
Unknown empty 6 ONBOARD DIMM_D2 Channel D
==== On-Board Devices =====================================
ATI Rage XL
Intel 82546EB Ethernet 1
Intel 82546EB Ethernet 2
ESB2 Integrated SATA Controller
NS PC87427 SIO3
==== Upgradeable Slots ====================================
ID Status Type Description
--- --------- ---------------- ----------------------------
1 available PCI Express FH Slot 1, PCI EXP x8
1 available PCI Express LP Slot 1, PCI EXP x8
10 available PCI Express I/O Module
These servers were connected with network link Ethernet 100Mb. The first
server (AMQP broker) powered by
Debian GNU/Linux Etch. Versions of installed software listed below:
# cat /etc/debian_version
4.0
# uname -sr
Linux 2.6.18-6-686-bigmem
# free
total used free shared buffers cached
Mem: 4139508 514148 3625360 0 210648 150388
-/+ buffers/cache: 153112 3986396
Swap: 4194296 0 4194296
Erlang version (stable debian distribution) :
# dpkg -l erlang\* | grep ii
ii erlang-base 11.b.2-4 Concurrent, real-time, distributed
functiona
ii erlang-nox 11.b.2-4 Concurrent, real-time, distributed
functiona
# erl
Erlang (BEAM) emulator version 5.5.2 [source] [async-threads:0]
[kernel-poll:false]
Eshell V5.5.2 (abort with ^G)
RabbitMQ version:
# apt-cache show rabbitmq-server | grep Version
Version: 1.3.0-1
We have modified startup script for handling more than 1024 tcp/connections:
--- rabbitmq-server.orig 2008-04-07 21:59:48.000000000 +0400
+++ /etc/init.d/rabbitmq-server 2008-04-04 18:05:25.000000000 +0400
@@ -24,8 +24,10 @@
set -e
cd /
+ulimit -n 65535
+
start_rabbitmq () {
set +e
su rabbitmq -s /bin/sh -c "$DAEMON start_all ${NODE_COUNT}" >
/var/log/rabbitmq/startup.log 2> /var/log/rabbitmq/startup.err
case "$?" in
Another midfications were done for normal mnesia work (errors listed below)
ERROR REPORT==== 4-Apr-2008::18:29:14 ===
Error in process <0.20713.0> on node 'rabbit@altair' with exit value:
{{case_clause,{error,{system_limit,"Cannot create an ets table for
the local transaction
store",{system_limit,[{ets,new,[mnesia_trans_store,[bag,public]]},{mnesia_tm,doit_loop,1},{mnesia_sp,init_proc,4},{
proc_lib...
and for increasing common throughput
# diff -u rabbitmq-server.orig /usr/sbin/rabbitmq-server
--- rabbitmq-server.orig 2008-04-07 22:27:26.000000000 +0400
+++ /usr/sbin/rabbitmq-server 2008-04-07 22:28:40.000000000 +0400
@@ -28,7 +28,7 @@
[ "x" = "x$NODE_IP_ADDRESS" ] && NODE_IP_ADDRESS=0.0.0.0
[ "x" = "x$NODE_PORT" ] && NODE_PORT=5672
-ERL_ARGS="+K true +A30 -kernel inet_default_listen_options
[{sndbuf,16384},{recbuf,4096}]"
+ERL_ARGS="-env ERL_MAX_ETS_TABLES 10240 -env ERL_MAX_PORTS 10240 +K
true +A300 +P512000 -kernel inet_default_listen_options
[{sndbuf,65535},{recbuf,65535},{reuseaddr,true}] -smp auto"
CLUSTER_CONFIG_FILE=/etc/default/rabbitmq_cluster.config
CONFIG_FILE=/etc/default/rabbitmq
There is a system state after rabbitmq startup:
top - 22:41:58 up 3 days, 5:10, 3 users, load average: 0.00, 0.00, 0.00
Tasks: 116 total, 1 running, 115 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 4139508k total, 572228k used, 3567280k free, 212784k buffers
Swap: 4194296k total, 0k used, 4194296k free, 188600k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31089 rabbitmq 15 0 2499m 15m 1620 S 0 0.4 0:00.29 beam.smp
30909 rabbitmq 15 0 1812 380 252 S 0 0.0 0:00.00 epmd
31085 rabbitmq 18 0 4176 1548 1080 S 0 0.0 0:00.01
rabbitmq-server
31410 rabbitmq 17 0 1808 452 360 S 0 0.0 0:00.00
inet_gethost
31411 rabbitmq 18 0 1852 580 468 S 0 0.0 0:00.00
inet_gethost
The second server (producer & consumer clients) powered by Solaris 10
07/. Versions of installed software listed below:
$ java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)
Client source code attached to this message.
So, let's try to start 100 producer's and
100 consumer's. Each producer generate 10 msgs/sec (t
1000 msgs/sec at all)
$ java -jar RabbitmqFastMessagingProducerTest.jar 100 > client.log
System snapshot:
top - 22:50:39 up 3 days, 5:19, 3 users, load average: 0.51, 0.11, 0.04
Tasks: 116 total, 1 running, 115 sleeping, 0 stopped, 0 zombie
Cpu(s): 30.1%us, 5.3%sy, 0.0%ni, 64.2%id, 0.0%wa, 0.0%hi, 0.4%si,
0.0%st
Mem: 4139508k total, 590664k used, 3548844k free, 212844k buffers
Swap: 4194296k total, 0k used, 4194296k free, 188960k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31089 rabbitmq 15 0 2520m 33m 1620 S 281 0.8 0:45.94 beam.smp
30909 rabbitmq 15 0 1812 380 252 S 0 0.0 0:00.00 epmd
31085 rabbitmq 18 0 4176 1548 1080 S 0 0.0 0:00.01 rabbitmq-server
31410 rabbitmq 17 0 1808 452 360 S 0 0.0 0:00.00 inet_gethost
31411 rabbitmq 18 0 1852 580 468 S 0 0.0 0:00.00 inet_gethost
Client eat about 5-7% CPU.
Client log file listed below:
> CLIENT_PRODUCER_THREAD_ID: 63 TIME: 1207594715030 MESSAGE: 1032 TIME: 1207594715030
> CLIENT_PRODUCER_THREAD_ID: 85 TIME: 1207594715030 MESSAGE: 1031 TIME: 1207594715030
> CLIENT_PRODUCER_THREAD_ID: 62 TIME: 1207594715030 MESSAGE: 1033 TIME: 1207594715030
> CLIENT_PRODUCER_THREAD_ID: 4 TIME: 1207594715030 MESSAGE: 1031 TIME: 1207594715030
> CLIENT_CONSUMER_THREAD_ID: 80 TIME: 1207594715051 MESSAGE: 1032 TIME: 1207594715030
> CLIENT_CONSUMER_THREAD_ID: 85 TIME: 1207594715051 MESSAGE: 1031 TIME: 1207594715030
> CLIENT_CONSUMER_THREAD_ID: 63 TIME: 1207594715052 MESSAGE: 1032 TIME: 1207594715030
Ok, try to calculate delay:
> $ tail -f client.log | awk '/CLIENT_CONSUMER_THREAD_ID/ {print "DELAY: " $4-$8 " " $0}'
> DELAY: 15 CLIENT_CONSUMER_THREAD_ID: 96 TIME: 1207594667285 MESSAGE: 596 TIME: 1207594667270
> DELAY: 15 CLIENT_CONSUMER_THREAD_ID: 76 TIME: 1207594667285 MESSAGE: 595 TIME: 1207594667270
> DELAY: 16 CLIENT_CONSUMER_THREAD_ID: 3 TIME: 1207594667286 MESSAGE: 596 TIME: 1207594667270
> DELAY: 2 CLIENT_CONSUMER_THREAD_ID: 49 TIME: 1207594667292 MESSAGE: 596 TIME: 1207594667290
> DELAY: 3 CLIENT_CONSUMER_THREAD_ID: 63 TIME: 1207594667293 MESSAGE: 596 TIME: 1207594667290
> DELAY: 3 CLIENT_CONSUMER_THREAD_ID: 0 TIME: 1207594667303 MESSAGE: 594 TIME: 1207594667300
> DELAY: 3 CLIENT_CONSUMER_THREAD_ID: 33 TIME: 1207594667303 MESSAGE: 596 TIME: 1207594667300
> DELAY: 43 CLIENT_CONSUMER_THREAD_ID: 12 TIME: 1207594667303 MESSAGE: 596 TIME: 1207594667260
> DELAY: 44 CLIENT_CONSUMER_THREAD_ID: 65 TIME: 1207594667304 MESSAGE: 593 TIME: 1207594667260
> DELAY: 4 CLIENT_CONSUMER_THREAD_ID: 42 TIME: 1207594667304 MESSAGE: 595 TIME: 1207594667300
> DELAY: 5 CLIENT_CONSUMER_THREAD_ID: 45 TIME: 1207594667305 MESSAGE: 596 TIME: 1207594667300
> DELAY: 45 CLIENT_CONSUMER_THREAD_ID: 29 TIME: 1207594667305 MESSAGE: 594 TIME: 1207594667260
> DELAY: 2 CLIENT_CONSUMER_THREAD_ID: 39 TIME: 1207594667312 MESSAGE: 596 TIME: 1207594667310
> DELAY: 6 CLIENT_CONSUMER_THREAD_ID: 54 TIME: 1207594667336 MESSAGE: 597 TIME: 1207594667330
> DELAY: 7 CLIENT_CONSUMER_THREAD_ID: 85 TIME: 1207594667337 MESSAGE: 595 TIME: 1207594667330
> DELAY: 8 CLIENT_CONSUMER_THREAD_ID: 22 TIME: 1207594667338 MESSAGE: 597 TIME: 1207594667330
> DELAY: 8 CLIENT_CONSUMER_THREAD_ID: 79 TIME: 1207594667338 MESSAGE: 596 TIME: 1207594667330
>
So, the latency between 2-50 ms. It's suitable result.
We have increased thread count at the next step
> $ java -jar RabbitmqFastMessagingProducerTest.jar 500 > client.log
> $ tail -f client.log | awk '/CLIENT_CONSUMER_THREAD_ID/ {print "DELAY: " $4-$8 " " $0}'
> DELAY: 23338 CLIENT_CONSUMER_THREAD_ID: 367 TIME: 1207595791068 MESSAGE: 9 TIME: 1207595767730
> DELAY: 23210 CLIENT_CONSUMER_THREAD_ID: 417 TIME: 1207595791070 MESSAGE: 9 TIME: 1207595767860
> DELAY: 23326 CLIENT_CONSUMER_THREAD_ID: 464 TIME: 1207595791117 MESSAGE: 9 TIME: 1207595767791
> DELAY: 23147 CLIENT_CONSUMER_THREAD_ID: 481 TIME: 1207595791117 MESSAGE: 9 TIME: 1207595767970
> DELAY: 23327 CLIENT_CONSUMER_THREAD_ID: 386 TIME: 1207595791117 MESSAGE: 9 TIME: 1207595767790
> DELAY: 23197 CLIENT_CONSUMER_THREAD_ID: 469 TIME: 1207595791117 MESSAGE: 9 TIME: 1207595767920
> DELAY: 23984 CLIENT_CONSUMER_THREAD_ID: 322 TIME: 1207595791155 MESSAGE: 11 TIME: 1207595767171
> DELAY: 23307 CLIENT_CONSUMER_THREAD_ID: 350 TIME: 1207595791157 MESSAGE: 9 TIME: 1207595767850
> DELAY: 23158 CLIENT_CONSUMER_THREAD_ID: 453 TIME: 1207595791158 MESSAGE: 9 TIME: 1207595768000
> DELAY: 23258 CLIENT_CONSUMER_THREAD_ID: 306 TIME: 1207595791158 MESSAGE: 9 TIME: 1207595767900
> DELAY: 23283 CLIENT_CONSUMER_THREAD_ID: 356 TIME: 1207595791213 MESSAGE: 9 TIME: 1207595767930
> DELAY: 23294 CLIENT_CONSUMER_THREAD_ID: 256 TIME: 1207595791214 MESSAGE: 9 TIME: 1207595767920
> DELAY: 23144 CLIENT_CONSUMER_THREAD_ID: 456 TIME: 1207595791214 MESSAGE: 9 TIME: 1207595768070
> DELAY: 24063 CLIENT_CONSUMER_THREAD_ID: 112 TIME: 1207595791214 MESSAGE: 11 TIME: 1207595767151
> DELAY: 23144 CLIENT_CONSUMER_THREAD_ID: 484 TIME: 1207595791214 MESSAGE: 9 TIME: 1207595768070
Latency increased to 20-25 sec (not suitable).
System state snapshot:
top - 23:22:10 up 3 days, 5:51, 3 users, load average: 4.91, 2.89,
1.56
Tasks: 116 total, 1 running, 115 sleeping, 0 stopped, 0 zombie
Cpu(s): 45.9%us, 5.9%sy, 0.0%ni, 47.3%id, 0.0%wa, 0.1%hi, 0.8%si,
0.0%st
Mem: 4139508k total, 1155792k used, 2983716k free, 213068k buffers
Swap: 4194296k total, 0k used, 4194296k free, 196008k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31566 rabbitmq 15 0 3062m 572m 1620 S 412 14.2 12:14.58 beam.smp
30909 rabbitmq 15 0 1812 380 252 S 0 0.0 0:00.00 epmd
31562 rabbitmq 18 0 4172 1548 1080 S 0 0.0 0:00.00
rabbitmq-server
31887 rabbitmq 18 0 1808 452 360 S 0 0.0 0:00.00
inet_gethost
31888 rabbitmq 19 0 1852 576 468 S 0 0.0 0:00.00
inet_gethost
Try to increase threads up to 1000:
> $ java -jar RabbitmqFastMessagingProducerTest.jar 1000 > client.log
> $ tail -f client.log | awk '/CLIENT_CONSUMER_THREAD_ID/ {print "DELAY: " $4-$8 " " $0}'
> DELAY: 78805 CLIENT_CONSUMER_THREAD_ID: 562 TIME: 1207597161505 MESSAGE: 577 TIME: 1207597082700
> DELAY: 78843 CLIENT_CONSUMER_THREAD_ID: 602 TIME: 1207597161593 MESSAGE: 577 TIME: 1207597082750
> DELAY: 31985 CLIENT_CONSUMER_THREAD_ID: 483 TIME: 1207597161687 MESSAGE: 84 TIME: 1207597129702
> DELAY: 59055 CLIENT_CONSUMER_THREAD_ID: 694 TIME: 1207597161896 MESSAGE: 235 TIME: 1207597102841
> DELAY: 79510 CLIENT_CONSUMER_THREAD_ID: 562 TIME: 1207597162311 MESSAGE: 578 TIME: 1207597082801
> DELAY: 79512 CLIENT_CONSUMER_THREAD_ID: 602 TIME: 1207597162372 MESSAGE: 578 TIME: 1207597082860
> DELAY: 32710 CLIENT_CONSUMER_THREAD_ID: 483 TIME: 1207597162521 MESSAGE: 85 TIME: 1207597129811
> DELAY: 59680 CLIENT_CONSUMER_THREAD_ID: 694 TIME: 1207597162630 MESSAGE: 236 TIME: 1207597102950
> DELAY: 79967 CLIENT_CONSUMER_THREAD_ID: 562 TIME: 1207597162878 MESSAGE: 579 TIME: 1207597082911
> DELAY: 79953 CLIENT_CONSUMER_THREAD_ID: 602 TIME: 1207597162923 MESSAGE: 579 TIME: 1207597082970
> DELAY: 33231 CLIENT_CONSUMER_THREAD_ID: 483 TIME: 1207597163152 MESSAGE: 86 TIME: 1207597129921
Latency become unsuitable, and errors detected in client log:
> Apr 7, 2008 11:39:54 PM rabbitmqfastmessagingproducertest.FastMessagingProducer run
> SEVERE: null
> java.net.SocketException: Socket closed
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at java.io.DataOutputStream.flush(DataOutputStream.java:106)
> at com.rabbitmq.client.impl.SocketFrameHandler.writeFrame(SocketFrameHandler.java:156)
> at com.rabbitmq.client.impl.AMQConnection.writeFrame(AMQConnection.java:297)
> at com.rabbitmq.client.impl.AMQCommand.transmit(AMQCommand.java:175)
> at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:369)
> at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:350)
> at rabbitmqfastmessagingproducertest.FastMessagingProducer.run(FastMessagingProducer.java:83)
>
there are also errors in rabbitmq log:
> =WARNING REPORT==== 7-Apr-2008::23:34:04 ===
> Mnesia(rabbit@altair): ** WARNING ** Mnesia is overloaded: {mnesia_tm,
> message_queue_len,
> [732,626]}
>
>
CPU and RAM at AMQP broker server only half done.
Is there any way to increse common system throughput up to 10K msgs/sec?
Any ideas?
Thanks in advance
--
Alexey Slynko
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 09, 2008 3:56 pm |
|
|
|
Guest
|
Hi Alexey,
Alexey Slynko wrote:
>
> Hi,
>
> we have done some stress tests of rabbitmq. Our main goal was the ~10K
> messages per second and maximum cpu & ram usage. Two servers with equal
> configuration listed below were used for this task.
>
What is your projected number of clients (producers and consumers combined)? In your tests
below, it looks to me like you had 200, 1000 and 2000 clients - are these your expected
levels? Each client is a socket. I think you might get higher throughput by reducing the
number of clients.
> There is a system state after rabbitmq startup:
>
> top - 22:41:58 up 3 days, 5:10, 3 users, load average: 0.00, 0.00, 0.00
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 31089 rabbitmq 15 0 2499m 15m 1620 S 0 0.4 0:00.29 beam.smp
>
> So, let's try to start 100 producer's and
> 100 consumer's. Each producer generate 10 msgs/sec (t
> 1000 msgs/sec at all)
May I suggest increasing the number of messages per second as an alternative test (instead
of increasing the number of clients)?
>
> $ java -jar RabbitmqFastMessagingProducerTest.jar 100 > client.log
>
> System snapshot:
>
> top - 22:50:39 up 3 days, 5:19, 3 users, load average: 0.51, 0.11, 0.04
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>
> 31089 rabbitmq 15 0 2520m 33m 1620 S 281 0.8 0:45.94 beam.smp
>
>> $ java -jar RabbitmqFastMessagingProducerTest.jar 500 > client.log
>
> top - 23:22:10 up 3 days, 5:51, 3 users, load average: 4.91, 2.89,
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>
> 31566 rabbitmq 15 0 3062m 572m 1620 S 412 14.2 12:14.58 beam.smp
It also looks like you restarted the broker before you ran the last top above (changed
PID). Is there a way to capture its memory footprint right after restart? The difference
in virt mem is 500M, which is 20% of what the first top shows.
I think one of your your biggest bottlenecks in this case is the number of sockets that
you ask your OS to juggle at the same time (I may be wrong however). Things you might want
to try:
1. reduce the number of clients
2. reduce the number of sockets each broker has to open by setting up a RabbitMQ cluster
- Dmitriy
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 09, 2008 9:50 pm |
|
|
|
Guest
|
Alexey,
Alexey Slynko wrote:
> we have done some stress tests of rabbitmq. Our main goal was the ~10K
> messages per second and maximum cpu & ram usage. Two servers with equal
> configuration listed below were used for this task.
> Intel(R) Xeon(R) CPU E5345 @ 2.33GHz CPU1
> Intel(R) Xeon(R) CPU E5345 @ 2.33GHz CPU2
You shouldn't have any trouble hitting ~10k mps on these boxes. We have
achieved that on machines with much lower specs.
> These servers were connected with network link Ethernet 100Mb.
That's rather slow, though you probably won't be hitting the limits in
your tests. Check the stats on the network interface to get an idea how
much headroom you have.
> Erlang version (stable debian distribution) :
>
> # dpkg -l erlang\* | grep ii
> ii erlang-base 11.b.2-4 Concurrent, real-time, distributed
> functiona
> ii erlang-nox 11.b.2-4 Concurrent, real-time, distributed
> functiona
Any chance you could try the tests with R11B-5? Most of our testing has
been done on that. I doubt it will make much difference but at the very
least it will make it easier for us to compare results.
> Another midfications were done for normal mnesia work (errors listed below)
>
> ERROR REPORT==== 4-Apr-2008::18:29:14 ===
> Error in process <0.20713.0> on node 'rabbit@altair' with exit value:
> {{case_clause,{error,{system_limit,"Cannot create an ets table for
> the local transaction
> store",{system_limit,[{ets,new,[mnesia_trans_store,[bag,public]]},{mnesia_tm,doit_loop,1},{mnesia_sp,init_proc,4},{
>
> proc_lib...
We have never seen this before. At what point during your tests did you
get this error?
> and for increasing common throughput
>
> # diff -u rabbitmq-server.orig /usr/sbin/rabbitmq-server
> --- rabbitmq-server.orig 2008-04-07 22:27:26.000000000 +0400
> +++ /usr/sbin/rabbitmq-server 2008-04-07 22:28:40.000000000 +0400
> @@ -28,7 +28,7 @@
> [ "x" = "x$NODE_IP_ADDRESS" ] && NODE_IP_ADDRESS=0.0.0.0
> [ "x" = "x$NODE_PORT" ] && NODE_PORT=5672
>
> -ERL_ARGS="+K true +A30 -kernel inet_default_listen_options
> [{sndbuf,16384},{recbuf,4096}]"
> +ERL_ARGS="-env ERL_MAX_ETS_TABLES 10240 -env ERL_MAX_PORTS 10240 +K
> true +A300 +P512000 -kernel inet_default_listen_options
> [{sndbuf,65535},{recbuf,65535},{reuseaddr,true}] -smp auto"
> CLUSTER_CONFIG_FILE=/etc/default/rabbitmq_cluster.config
> CONFIG_FILE=/etc/default/rabbitmq
These should all be fine except I have some concerns about the "-smp
auto", given how old a version of Erlang/OTP are running. Did you test
that adding the flag indeed improves performance?
Note that RabbitMQ when running with Erlang/OTP R11B (rather than the
more recent R12) will not benefit much (if at all) from the multiple
cores when running with -smp. In our experiments we have been getting
much better results when configuring a local cluster of one non-smp node
per code. So I'd recommend you do that.
> Client source code attached to this message.
The following will all impact performance:
- The queues are not auto-deleting and aren't being deleted explicitly,
and your queue/exchange naming scheme is deterministic. Unless you
restart the server between tests or subsequent tests will be affected by
the queues from earlier tests. I'd also recommend clearing the mnesia
dir prior to starting rabbit, just to make sure that there aren't any
stray exchanges, queues or persistent messages.
- The consumer explicitly acknowledges each message. Would
bulk-acknowledgment or auto-acknowledgment be an option?
- The tests use a single topic exchange, with a distinct routing/binding
key for each producer/consumer pair. That is a rather peculiar set up
and may well run into performance problems for high numbers of queues.
The reason is that currently topic exchange routing simply pattern
matches the routing key against each binding key in term, i.e. matching
time is linear in the number of queues. That's on our todo list to
change - we used to have some caching logic in pre-1.3.0 versions but
removed that because it exhibited unbounded memory growth when people
used UIDs for routing keys. Anyway, I'd suggest you use a direct
exchange. All you should have to do is change the type in the exchange
declaration; the rest of your code ought to work unchanged.
- You start lots of producers and consumer and each establishes a
separate connection. Dmitriy already pointed out several reasons why
that may be affecting performance. Another reason is that connection
establishment and teardown is quite expensive in RabbitMQ. Queue
creation, binding and deletion are quite expensive too. I notice you
have some "sleep" statements in your code, presumably to prevent the set
up tasks from interfering with the measurements. However, given the high
number of producers and consumers you are creating I suspect you will
still get interference. The mnesia errors/warnings you are seeing are an
indication of that because the sending/receiving of messages does not
involve any mnesia writes but connection, queue, exchange and binding
creation all do. If you really want to measure throughput for that many
connections and queues then I'd suggest you make sure they are all
created prior to any messages being sent.
You may also want to run one of the test programs supplied with the
RabbitMQ Java client packages, such as MulticastMain, e.g.
sh ./runjava.sh com.rabbitmq.examples.MulticastMain -h <host> -a
which reports on throughput and latency.
I hope the above helps. Please do let us know what results you are getting.
Regards,
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Apr 10, 2008 4:23 am |
|
|
|
Guest
|
> You shouldn't have any trouble hitting ~10k mps on these boxes. We have
> achieved that on machines with much lower specs.
>
If there are 100 consumers for the feed, 10k of unique messages per
second equals to 1,010,000 messages a second over the wire, no? No way a
100MbE can handle that amount of data.
Martin
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Apr 10, 2008 6:31 am |
|
|
|
Guest
|
Martin,
Martin Sustrik wrote:
>
>> You shouldn't have any trouble hitting ~10k mps on these boxes. We
>> have achieved that on machines with much lower specs.
>>
> If there are 100 consumers for the feed, 10k of unique messages per
> second equals to 1,010,000 messages a second over the wire, no? No way a
> 100MbE can handle that amount of data.
That's what I thought at first too, but looking at the code the set up
is such that each consumer only consumes the messages of one producer.
So the number of outbound messages is the same as the number of inbound
messages.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 16, 2008 9:15 am |
|
|
|
Guest
|
|
| Back to top |
|
| 0x6e6562 |
| Posted: Wed Apr 16, 2008 9:34 am |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
Hi Andrew,
On 16 Apr 2008, at 10:15, Andrew V. Statsenko wrote:
> In real life we are looking for fast messaging middleware which can
> interconnect 10-100K flash clients per server with _very_ low latency
> (each client send & recieve 4 mgs per sec) and perfomance/latency
> degradation with high number of sockets is important fo us.
Have you written your own flash client for AMQP?
Ben
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
 
|
| Guest |
| Posted: Wed Apr 16, 2008 10:26 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 16, 2008 11:46 am |
|
|
|
Guest
|
В Срд, 09/04/2008 в 22:50 +0100, Matthias Radestock пишет:
Hello Matthias !
Fisrt off all many thank for help, second I am very sorry about my bad
written english.
We are continue testing RabbitMQ with Alexey Slynko and here the some
results.
> > Erlang version (stable debian distribution) :
> >
> > # dpkg -l erlang\* | grep ii
> > ii erlang-base 11.b.2-4 Concurrent, real-time, distributed
> > functiona
> > ii erlang-nox 11.b.2-4 Concurrent, real-time, distributed
> > functiona
>
> Any chance you could try the tests with R11B-5? Most of our testing has
> been done on that. I doubt it will make much difference but at the very
> least it will make it easier for us to compare results.
Chance is 100% . Just sey that we are have to rebuild. Current,
backported from Etch, Erlang is:
# dpkg -l erlang\* | grep ii
ii erlang-base 11.b.5dfsg-12 Concurrent, real-time, distributed
functiona
ii erlang-nox 11.b.5dfsg-12 Concurrent, real-time, distributed
functiona
as you say.
> > Another midfications were done for normal mnesia work (errors listed below)
> >
> > ERROR REPORT==== 4-Apr-2008::18:29:14 ===
> > Error in process <0.20713.0> on node 'rabbit at altair' with exit value:
> > {{case_clause,{error,{system_limit,"Cannot create an ets table for
> > the local transaction
> > store",{system_limit,[{ets,new,[mnesia_trans_store,[bag,public]]},{mnesia_tm,doit_loop,1},{mnesia_sp,init_proc,4},{
> >
> > proc_lib...
>
> We have never seen this before. At what point during your tests did you
> get this error?
Test starts, after 7-15 min Erlang eat a lot off memory and give the
errors,
sometime crash.
> These should all be fine except I have some concerns about the "-smp
> auto", given how old a version of Erlang/OTP are running. Did you test
> that adding the flag indeed improves performance?
Yes. Then I use -smp flag the Erlang/OTP eating all 8 CPU core, without
- 1.
>
> Note that RabbitMQ when running with Erlang/OTP R11B (rather than the
> more recent R12) will not benefit much (if at all) from the multiple
> cores when running with -smp. In our experiments we have been getting
> much better results when configuring a local cluster of one non-smp node
> per code. So I'd recommend you do that.
I am newbe man in Erlang/OTP system and correctly configuring a local
cluster
is not easy for me. With SMP mode beam.smp can utilize up to 790% off
this server.
> The following will all impact performance:
>
> - The queues are not auto-deleting and aren't being deleted explicitly,
> and your queue/exchange naming scheme is deterministic. Unless you
> restart the server between tests or subsequent tests will be affected by
> the queues from earlier tests. I'd also recommend clearing the mnesia
> dir prior to starting rabbit, just to make sure that there aren't any
> stray exchanges, queues or persistent messages.
Well,
# invoke-rc.d rabbitmq-server stop
Stopping rabbitmq-server: rabbitmq-server.
# rm -f /var/lib/rabbitmq/mnesia/rabbit/*
# invoke-rc.d rabbitmq-server start
Starting rabbitmq-server: SUCCESS
rabbitmq-server.
>
> - The consumer explicitly acknowledges each message. Would
> bulk-acknowledgment or auto-acknowledgment be an option?
OK, I was delete the acknowledges each message code
- // channel.basicAck(envelope.getDeliveryTag(), false);
start the test
$ java -jar RabbitmqFastMessagingProducerTest.jar 1000 > client.log
after ~ 5 min the server side looks
top - 15:10:19 up 11 days, 21:39, 2 users, load average: 5.93, 2.69,
1.09
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
Cpu(s): 58.2%us, 18.9%sy, 0.0%ni, 21.4%id, 0.0%wa, 0.4%hi, 1.1%si,
0.0%st
Mem: 4139508k total, 2233588k used, 1905920k free, 286108k buffers
Swap: 4194296k total, 0k used, 4194296k free, 826336k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16082 rabbitmq 25 0 1133m 900m 1696 S 615 22.3 16:55.04 beam.smp
23983 rabbitmq 15 0 1828 388 256 S 0 0.0 0:00.00 epmd
16078 rabbitmq 20 0 4172 1548 1080 S 0 0.0 0:00.00
rabbitmq-server
16404 rabbitmq 17 0 1824 472 368 S 0 0.0 0:00.00
inet_gethost
16405 rabbitmq 18 0 1868 592 472 S 0 0.0 0:00.00
inet_gethost
and the client side
$ tail -f client.log | awk '/CLIENT_CONSUMER_THREAD_ID/{print "DELAY: "
$4-$8 " " $0}'
DELAY: 188894 CLIENT_CONSUMER_THREAD_ID: 2 TIME: 1208344442697 MESSAGE:
23 TIME: 1208344253803
DELAY: 187904 CLIENT_CONSUMER_THREAD_ID: 951 TIME: 1208344442697
MESSAGE: 22 TIME: 1208344254793
DELAY: 187807 CLIENT_CONSUMER_THREAD_ID: 871 TIME: 1208344442698
MESSAGE: 22 TIME: 1208344254891
DELAY: 188168 CLIENT_CONSUMER_THREAD_ID: 706 TIME: 1208344442698
MESSAGE: 22 TIME: 1208344254530
DELAY: 188267 CLIENT_CONSUMER_THREAD_ID: 630 TIME: 1208344442698
MESSAGE: 22 TIME: 1208344254431
DELAY: 189608 CLIENT_CONSUMER_THREAD_ID: 626 TIME: 1208344442698
MESSAGE: 23 TIME: 1208344253090
DELAY: 188127 CLIENT_CONSUMER_THREAD_ID: 113 TIME: 1208344442698
MESSAGE: 22 TIME: 1208344254571
DELAY: 188596 CLIENT_CONSUMER_THREAD_ID: 519 TIME: 1208344442698
MESSAGE: 22 TIME: 1208344254102
The delay is about 3 min. I can't understand why.
> You may also want to run one of the test programs supplied with the
> RabbitMQ Java client packages, such as MulticastMain, e.g.
> sh ./runjava.sh com.rabbitmq.examples.MulticastMain -h <host> -a
> which reports on throughput and latency.
Well, the I start signle producer/consumer thread all looks good:
$ sh ./runjava.sh com.rabbitmq.examples.MulticastMain -h host.domain.tld
-a
starting consumer #0
starting producer #0
recving rate: 7780 msg/s, min/avg/max latency: 4083/109443/165431
microseconds
sending rate: 10679 msg/s
recving rate: 9734 msg/s, min/avg/max latency: 109790/135292/163872
microseconds
sending rate: 9821 msg/s
recving rate: 9873 msg/s, min/avg/max latency: 109995/134968/160787
microseconds
sending rate: 9848 msg/s
recving rate: 9969 msg/s, min/avg/max latency: 107159/132702/158851
microseconds
sending rate: 10083 msg/s
recving rate: 9868 msg/s, min/avg/max latency: 108387/134192/160497
microseconds
But, then I start 100 producer/consumer threads latency going to be
high 0.3->20 sec:
$ sh ./runjava.sh com.rabbitmq.examples.MulticastMain
-h host.domain.tld -a -x 100 -y 100 | grep recving
recving rate: 0 msg/s, min/avg/max latency: 11195/11195/11195
microseconds
recving rate: 33217 msg/s, min/avg/max latency: 10113/345828/996901
microseconds
recving rate: 27192 msg/s, min/avg/max latency: 58042/1010474/1997839
microseconds
recving rate: 33569 msg/s, min/avg/max latency: 65700/1562317/2997350
microseconds
recving rate: 24304 msg/s, min/avg/max latency: 90050/2142151/3991946
microseconds
recving rate: 37388 msg/s, min/avg/max latency: 111498/2970700/4996836
microseconds
recving rate: 28715 msg/s, min/avg/max latency: 118559/3476202/5998178
microseconds
recving rate: 28453 msg/s, min/avg/max latency: 144319/4098792/6999516
microseconds
recving rate: 27348 msg/s, min/avg/max latency: 157363/4722565/7998155
microseconds
recving rate: 27508 msg/s, min/avg/max latency: 182090/5381463/9003343
microseconds
recving rate: 27007 msg/s, min/avg/max latency: 192525/6034385/9982716
microseconds
recving rate: 26638 msg/s, min/avg/max latency: 207776/6694654/10998061
microseconds
recving rate: 27001 msg/s, min/avg/max latency: 211793/7335019/12002072
microseconds
recving rate: 26616 msg/s, min/avg/max latency: 244324/7996319/13001783
microseconds
recving rate: 26056 msg/s, min/avg/max latency: 231526/8642121/13997488
microseconds
recving rate: 26521 msg/s, min/avg/max latency: 252036/9327910/15016590
microseconds
recving rate: 26018 msg/s, min/avg/max latency: 262150/10006353/16007951
microseconds
recving rate: 26431 msg/s, min/avg/max latency: 264835/10697607/17017128
microseconds
recving rate: 26018 msg/s, min/avg/max latency: 342075/11366371/18016090
microseconds
recving rate: 25545 msg/s, min/avg/max latency: 273541/11965135/18987288
microseconds
recving rate: 25902 msg/s, min/avg/max latency: 280084/12749721/20008257
microseconds
recving rate: 25449 msg/s, min/avg/max latency: 304305/13347575/21019395
microseconds
recving rate: 25473 msg/s, min/avg/max latency: 309149/13985349/22019055
microseconds
recving rate: 25658 msg/s, min/avg/max latency: 302950/14691935/23020086
microseconds
recving rate: 25564 msg/s, min/avg/max latency: 403575/15483426/24021188
microseconds
recving rate: 25639 msg/s, min/avg/max latency: 323600/15878397/25021019
microseconds
recving rate: 25553 msg/s, min/avg/max latency: 321453/16720349/25974209
microseconds
recving rate: 25747 msg/s, min/avg/max latency: 343184/17436193/27023608
microseconds
recving rate: 24954 msg/s, min/avg/max latency: 386340/17945129/28010304
microseconds
recving rate: 24919 msg/s, min/avg/max latency: 377575/18603424/29026385
microseconds
recving rate: 25226 msg/s, min/avg/max latency: 349285/19401619/30013216
microseconds
recving rate: 25074 msg/s, min/avg/max latency: 491382/20007042/31005415
microseconds
recving rate: 25906 msg/s, min/avg/max latency: 374276/20710481/32014250
microseconds
recving rate: 25153 msg/s, min/avg/max latency: 363636/21417328/33015581
microseconds
Here the result then I run this test in AQMP server host (localhost):
$ sh ./runjava.sh com.rabbitmq.examples.MulticastMain -h localhost -a -x
100 -y 100 | grep recving
recving rate: 0 msg/s, min/avg/max latency: 15532/15532/15532
microseconds
recving rate: 10911 msg/s, min/avg/max latency: 15538/358765/953624
microseconds
recving rate: 19022 msg/s, min/avg/max latency: 86565/907865/2021696
microseconds
recving rate: 18619 msg/s, min/avg/max latency: 116191/1471139/3014532
microseconds
recving rate: 21881 msg/s, min/avg/max latency: 112003/2051780/4021113
microseconds
recving rate: 19014 msg/s, min/avg/max latency: 139058/2687275/4929168
microseconds
recving rate: 18237 msg/s, min/avg/max latency: 184713/3311977/5929642
microseconds
recving rate: 18837 msg/s, min/avg/max latency: 213375/4023915/6917634
microseconds
recving rate: 21111 msg/s, min/avg/max latency: 177935/4640096/7928183
microseconds
recving rate: 16905 msg/s, min/avg/max latency: 167707/5139316/8939816
microseconds
recving rate: 16678 msg/s, min/avg/max latency: 209396/5903245/9921387
microseconds
recving rate: 19055 msg/s, min/avg/max latency: 241024/6477019/10940078
microseconds
recving rate: 17407 msg/s, min/avg/max latency: 309125/7134191/11945223
microseconds
recving rate: 18369 msg/s, min/avg/max latency: 232026/7839258/12949816
microseconds
recving rate: 18599 msg/s, min/avg/max latency: 246842/8434456/13956746
microseconds
recving rate: 18142 msg/s, min/avg/max latency: 261445/9040292/14955231
microseconds
recving rate: 19064 msg/s, min/avg/max latency: 253654/9718233/15976520
microseconds
recving rate: 19028 msg/s, min/avg/max latency: 274436/10391275/16977331
microseconds
recving rate: 17648 msg/s, min/avg/max latency: 339277/11079915/17959945
microseconds
recving rate: 18170 msg/s, min/avg/max latency: 662897/11848865/18972830
microseconds
recving rate: 19169 msg/s, min/avg/max latency: 307943/12328233/19945237
microseconds
recving rate: 17994 msg/s, min/avg/max latency: 342600/13105338/20889999
microseconds
recving rate: 18205 msg/s, min/avg/max latency: 359897/13805425/21926401
microseconds
recving rate: 18324 msg/s, min/avg/max latency: 439293/14389845/22942993
microseconds
recving rate: 16720 msg/s, min/avg/max latency: 409930/15036274/23980343
microseconds
recving rate: 18435 msg/s, min/avg/max latency: 928834/15825577/24938658
microseconds
recving rate: 19078 msg/s, min/avg/max latency: 401601/16257366/25940399
microseconds
recving rate: 17531 msg/s, min/avg/max latency: 445536/17090242/26952144
microseconds
recving rate: 18717 msg/s, min/avg/max latency: 842400/17750288/27990323
microseconds
recving rate: 19389 msg/s, min/avg/max latency: 374073/18312400/28965579
microseconds
It looks strange... like the "reciever" in rabbitmq working match
faster, then "processor" & "sender". Is this result correct ?
WBR,
Alter
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 16, 2008 12:43 pm |
|
|
|
Guest
|
Andrew,
Andrew V. Statsenko wrote:
> В Срд, 09/04/2008 в 22:50 +0100, Matthias Radestock пишет:
>> I have some concerns about the "-smp
>> auto", given how old a version of Erlang/OTP are running. Did you test
>> that adding the flag indeed improves performance?
>
> Yes. Then I use -smp flag the Erlang/OTP eating all 8 CPU core, without
> - 1.
> [...]
> I am newbe man in Erlang/OTP system and correctly configuring a local
> cluster
> is not easy for me. With SMP mode beam.smp can utilize up to 790% off
> this server.
Erlang in SMP mode will indeed happily use all your CPUs. It won't
necessarily go any faster though. In our experience - and I should
stress that this is for RabbitMQ and R11B-x only - it doesn't.
You don't need to know anything about Erlang to configure a local
cluster. Take a look at the http://www.rabbitmq.com/clustering.html - if
anything isn't clear in those instructions then please let us know ...
OTOH, you should only look into clustering once the other issues have
been resolved.
>> - The queues are not auto-deleting and aren't being deleted explicitly,
>> and your queue/exchange naming scheme is deterministic. Unless you
>> restart the server between tests or subsequent tests will be affected by
>> the queues from earlier tests. I'd also recommend clearing the mnesia
>> dir prior to starting rabbit, just to make sure that there aren't any
>> stray exchanges, queues or persistent messages.
>
> Well,
>
> # invoke-rc.d rabbitmq-server stop
> Stopping rabbitmq-server: rabbitmq-server.
> # rm -f /var/lib/rabbitmq/mnesia/rabbit/*
> # invoke-rc.d rabbitmq-server start
> Starting rabbitmq-server: SUCCESS
> rabbitmq-server.
ok. As long as you remember to run that between tests you should be fine.
>> - The consumer explicitly acknowledges each message. Would
>> bulk-acknowledgment or auto-acknowledgment be an option?
>
> OK, I was delete the acknowledges each message code
>
> - // channel.basicAck(envelope.getDeliveryTag(), false);
That's not sufficient. You need to change channel.basicConsume(...)
invocation to enable auto-ack. Otherwise your above change will result
in the server hanging on to all messages.
> Well, the I start signle producer/consumer thread all looks good:
>
> $ sh ./runjava.sh com.rabbitmq.examples.MulticastMain -h host.domain.tld
> -a
You should limit the sending rate with the -r flag. Otherwise the
producers will flood the server.
> $ sh ./runjava.sh com.rabbitmq.examples.MulticastMain
> -h host.domain.tld -a -x 100 -y 100 | grep recving
Note that this will result in the consumers receiving the messages from
*all* producers. The program is called "MulticastMain" for a reason :)
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 16, 2008 1:18 pm |
|
|
|
Guest
|
В Срд, 16/04/2008 в 13:48 +0100, Matthias Radestock пишет:
> Andrew,
> >> - The consumer explicitly acknowledges each message. Would
> >> bulk-acknowledgment or auto-acknowledgment be an option?
> >
> > OK, I was delete the acknowledges each message code
> >
> > - // channel.basicAck(envelope.getDeliveryTag(), false);
>
> That's not sufficient. You need to change channel.basicConsume(...)
> invocation to enable auto-ack. Otherwise your above change will result
> in the server hanging on to all messages.
Yes, I was look to the javadoc:
basicConsume(int ticket, java.lang.String queue, boolean noAck,
Consumer callback)
Start a non-nolocal, non-exclusive consumer, with a
server-generated consumerTag.
and the consumer code I running in latest reported here test is:
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume(ticket, topic, true, consumer);
Thread.sleep(5000);
for( int i = 0; i < MSG_COUNT; i++) {
QueueingConsumer.Delivery delivery = consumer.nextDelivery();
Envelope envelope = delivery.getEnvelope();
System.out.println("CLIENT_CONSUMER_THREAD_ID: " + this.THREAD_ID
+ " TIME: " + System.currentTimeMillis() + " " + new
String(delivery.getBody()) ) ;
}
Is this invocation "channel.basicConsume(ticket, topic, true,
consumer);" enable auto-ack ?
WBR,
Alter.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Apr 16, 2008 1:20 pm |
|
|
|
Guest
|
|
| Back to top |
|
| 0x6e6562 |
| Posted: Thu Apr 17, 2008 12:17 am |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
|
| Back to top |
|
| Guest |
| Posted: Tue Apr 22, 2008 2:06 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Tue Apr 22, 2008 4:50 am |
|
|
|
Guest
|
Kyle,
Kyle Salasko wrote:
> Do you have any benchmarks on running RabbitMQ with SMP mode on R12B-x? Is
> it still useful to run a local cluster with one instance per core, or does
> upgrading to R12B fix that issue?
R12B-2 is definitely an improvement over R11B-5 when it comes to running
in SMP mode, but we haven't done enough testing to determine whether it
does better than a one-node-per-core non-smp cluster.
Matthias.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 2
Goto page 1, 2 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
