Commits

Fred T-H  committed 77f566c

answering broken receives worries

  • Participants
  • Parent commits 22a87bf

Comments (0)

Files changed (1)

File Benchmarks.wiki

 Average received per client per second: 9.303013333333334
 }}}
 
-Analysis of the code shows the benchmark to be really focusing on the code that needs to be tested, except what would be the random selection of a peer. There's also a discrepancy between received and sent messages, which sounds a bit weird because it grows as there are more users when the difference grows. I'm not sure this is due to latency, dropped messages, random distribution or my code that tests stuff in a wrong way, but an eye should be kept out for this code.
+Analysis of the code shows the benchmark to be really focusing on the code that needs to be tested, except what would be the random selection of a peer. There's also a discrepancy between received and sent messages, which sounds a bit weird because it grows as there are more users. Testing proved that it was simply a question of changing the listener's delay to 1ms rather than 0ms. Such a test on another computer showed the sent messages go down and the received messages go up:
+
+With a 0ms delay (same as the benchmarks above)
+{{{
+#!text
+
+G:100   CPG:10  T:10
+Sent: 916084
+Received: 759593
+Average sent per second: 91608.4
+Average received per second: 75959.3
+Average sent per group: 9160.84
+Average received per group: 7595.93
+Average sent per client: 916.084
+Average received per client: 759.593
+Average sent per client per second: 91.60839999999999
+Average received per client per second: 75.9593
+
+}}}
+With 1ms delay:
+{{{
+#!text
+
+G:100   CPG:10  T:10
+Sent: 849655
+Received: 849139
+Average sent per second: 84965.5
+Average received per second: 84913.9
+Average sent per group: 8496.55
+Average received per group: 8491.39
+Average sent per client: 849.655
+Average received per client: 849.139
+Average sent per client per second: 84.96549999999999
+Average received per client per second: 84.9139
+
+}}}
+So the send:receive ratios improved from 1.2:1 to roughly 1:1. No messages were dropped in the previous benchmarks, only delayed. This is a good thing, obviously. The benchmark results should be updated accordingly.  The small differences remaining probably come from processes shutting down at the end of the benchmark without going through their mailbox.
 
 Otherwise, the benchmark shows a somewhat good load possible. At 7500 users, it's still possible to send a few dozen thousand messages per second. The bottleneck will probably be the web server, which means the code is //fast enough//, especially given real users aren't likely to be spamming that much. Most of the memory consumption (not shown here) appears to be from the messages sent and the history kept by each user (10 messages).