-
Notifications
You must be signed in to change notification settings - Fork 0
/
PERFDATA.txt
201 lines (149 loc) · 6.78 KB
/
PERFDATA.txt
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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
Latest kestrel:
Writing 1000 messages of size 512 took 0.443 seconds - 2257.902 msg/s - 1.128 MB/s (with 0 errors)
Reading 1000 messages took 0.439 seconds - 2277.962 m/s - 1.138 MB/s
Checking response correctness.
Found 0 errors in 1000 responses.
Non-persistent erq:
Writing 1000 messages of size 512 took 0.224 seconds - 4459.208 msg/s - 2.229 MB/s (with 0 errors)
Reading 1000 messages took 0.197 seconds - 5084.375 m/s - 2.542 MB/s
Checking response correctness.
Found 1 errors in 1000 responses.
Current erq with persistence via writing erlang terms to a file:
(This test was run on the same machine as the above to tests, but unfortunately the machine
is processing other work right now as well, so I was not able to get a sample with no
interference. I will update this when I can).
Writing 1024 messages of size 512 took 0.326 seconds - 3141.488 msg/s - 1.534 MB/s (with 0 errors)
Reading 1024 messages took 0.158 seconds - 6471.677 m/s - 3.160 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
By comparison, here is a test of kestrel with the same load:
Writing 1024 messages of size 512 took 0.656 seconds - 1561.905 msg/s - 0.763 MB/s (with 0 errors)
Reading 1024 messages took 0.815 seconds - 1256.800 m/s - 0.614 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
So it looks like we're still doing well.
Ok, I just tried running both several times in a row and got results
like this for Kestrel (this was one of the better runs):
Writing 1024 messages of size 512 took 0.198 seconds - 5179.696 msg/s - 2.529 MB/s (with 0 errors)
Reading 1024 messages took 0.219 seconds - 4680.010 m/s - 2.285 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
And results like this for erq (also one of the better runs):
Writing 1024 messages of size 512 took 0.284 seconds - 3605.266 msg/s - 1.760 MB/s (with 0 errors)
Reading 1024 messages took 0.154 seconds - 6647.928 m/s - 3.246 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
My guess is that hotspot kicked in a bit, which is why Kestrel got
faster (although this is still happening on a busy test system). We
are still beating kestrel consistently on reads, so that makes me
think that once we optimize the writes to be binaries or something
other than erlang-terms-as-text, we should be consistently beating
even a fully primed hotspot'd Kesterl.
FWIW, this is the Java version I am using:
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22, mixed mode)
The machine is a quad-core 2.4GHz Intel Xeon.
This brings up another interesting point which is concurrency. Here
are the results of running two tests in parallel like so:
./test.py -q queue1 > 1 & ./test.py -q queue2 > 2
Concurrent test of erq, 1:
Configuration:
Queue name: queue1
Payload size: 512
Number of messages messags: 1024
Writing 1024 messages of size 512 took 0.453 seconds - 2262.394 msg/s - 1.105 MB/s (with 0 errors)
Reading 1024 messages took 0.324 seconds - 3158.554 m/s - 1.542 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Configuration:
Queue name: queue2
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 0.777 seconds - 1317.693 msg/s - 0.643 MB/s (with 0 errors)
Reading 1024 messages took 0.279 seconds - 3672.859 m/s - 1.793 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Total write: 1.748 MB/s
Total read: 3.335 MB/s
Concurrent test of erq, 2:
Configuration:
Queue name: queue1
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 0.512 seconds - 2000.270 msg/s - 0.977 MB/s (with 0 errors)
Reading 1024 messages took 0.440 seconds - 2327.283 m/s - 1.136 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Configuration:
Queue name: queue2
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 0.606 seconds - 1689.014 msg/s - 0.825 MB/s (with 0 errors)
Reading 1024 messages took 0.357 seconds - 2866.373 m/s - 1.400 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Total write: 1.802 MB/s
Total read: 2.536 MB/s
Both tests are basically in line with running a single test against a single queue at once.
And the same two tests with Kestrel:
Configuration:
Queue name: queue1
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 0.512 seconds - 2000.270 msg/s - 0.977 MB/s (with 0 errors)
Reading 1024 messages took 0.440 seconds - 2327.283 m/s - 1.136 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Configuration:
Queue name: queue1
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 1.150 seconds - 890.690 msg/s - 0.435 MB/s (with 0 errors)
Reading 1024 messages took 0.802 seconds - 1276.822 m/s - 0.623 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Total write: 1.412 MB/s
Total read: 1.759 MB/s
And again:
Configuration:
Queue name: queue1
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 1.727 seconds - 592.766 msg/s - 0.289 MB/s (with 0 errors)
Reading 1024 messages took 0.613 seconds - 1670.874 m/s - 0.816 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Configuration:
Queue name: queue2
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 1.747 seconds - 586.284 msg/s - 0.286 MB/s (with 0 errors)
Reading 1024 messages took 0.561 seconds - 1826.784 m/s - 0.892 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.
Total read: 0.576 MB/s
Total write: 1.708 MB/s
It looks like Kestrel is going a lot slower handling two clients
against two queues at once. I am somewhat surprised by this, since it
is MINA driven and uses Scala actors and I would expect disk
contention for the journal to be the biggest factor. I can't rule out
the possibility that the other processes running on this machine just
happened to interfere more during my Kestrel tests than during my erq
tests, so I will hold off on doing any further tests until I can have
a nice clean test environment.
UPDATE: Oops, for the two concurrent tests of erq done above I did not
pass the -smp option to the emulator. I will correct this when I get
a chance to do more tests in a clean environment.
UPDATE (4/23/2009):
Here are the numbers for the latest version of the code (with the recently
added blocking functionality, although that code is not exercised in this
test) with the -smp flag:
Configuration:
Queue name: hurley
Payload size: 512
Number of messages: 1024
Writing 1024 messages of size 512 took 0.255 seconds - 4010.184 msg/s - 1.958 MB/s (with 0 errors)
Reading 1024 messages took 0.138 seconds - 7413.578 m/s - 3.620 MB/s
Checking response correctness.
Found 0 errors in 1024 responses.