Changes between Version 28 and Version 29 of PerformanceTesting
- Timestamp:
- 11/11/11 11:20:54 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PerformanceTesting
v28 v29 194 194 === OpenVPN 2.2.1/m1.large/UDP/IPv4/OpenSSL/20 clients (MP-2) === 195 195 196 '''Test name:''' 16-mp2-m1.large-openvpn221 197 198 '''Connection establishment''' 199 200 Client initialization phase took 2 seconds, judging from server's CPU load and network traffic levels. CPU utilization was 1.5-3.5% during this time.196 '''Test name:''' 16-mp2-m1.large-openvpn221 and 18-mp2-m1.large-openvpn221 197 198 '''Connection establishment''' 199 200 During both tests the client initialization phase took 2 seconds, judging from server's CPU load and network traffic levels. CPU utilization was on average 2,5% during this time. 201 201 202 202 '''Client statistics''' … … 206 206 ||16-mp2-m1.large-openvpn221||30s||average||20||339.85||9.27||0.4635|| 207 207 ||16-mp2-m1.large-openvpn221||60s||average||20||1168.61||18.91||0.9455|| 208 ||18-mp2-m1.large-openvpn221||10s||average||20||275.55||26.54||1.327|| 209 ||18-mp2-m1.large-openvpn221||30s||average||20||741.01||23.8||1.19|| 210 ||18-mp2-m1.large-openvpn221||60s||average||20||1176.57||18.78||0.939|| 208 211 209 212 '''Server statistics''' … … 213 216 ||16-mp2-m1.large-openvpn221||30s||72||8.82207||15.8551||30.9363||0.00511111|| 214 217 ||16-mp2-m1.large-openvpn221||60s||72||8.73214||15.6736||31.3002||0.252833|| 218 ||18-mp2-m1.large-openvpn221||10s||16||7.90512||15.4132||34.4907||0|| 219 ||18-mp2-m1.large-openvpn221||30s||41||8.6408||15.4649||31.9355||0.241415|| 220 ||18-mp2-m1.large-openvpn221||60s||65||8.66112||15.8789||31.0061||0.0868|| 215 221 216 222 '''Analysis''' … … 358 364 359 365 OpenVPN connection initialization seems to be much faster. 366 367 This head-tail effect can skew the results badly. These [wiki:PerformanceTesting#OpenVPN2.2.1m1.largeUDPIPv4OpenSSL20clientsMP-2 test results] are a good example: two identical tests can produce quite different results. There are a few ways to counter this effect: 368 369 * Lengthen the iperf test periods, so that any delays have a less pronounced effect 370 * Randomize the client connection to iperf 371 372 These changes combined should produce more reliable results test after test.