Changes between Version 3 and Version 4 of PerformanceTesting
- Timestamp:
- 10/04/11 11:47:50 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PerformanceTesting
v3 v4 9 9 The tests have several goals: 10 10 11 * Get an idea of OpenVPN performance with given parameters11 * Get an idea of OpenVPN performance with any given parameters 12 12 * Identify performance bottlenecks and fix the underlying issues insofar as possible 13 13 * Identify non-linear resource comsumption growth, e.g. find out if 100 clients consumes (significantly) more resources than that of 10 clients (multiplied by ten) 14 * Detect and fix abnormal behavior (e.g. partially configured clients) during peak load periods 14 15 15 16 = Prequisites = 16 17 17 Identification of performance bottlenecks requires plotting resource consumption, e.g. ''memory usage'' and ''processor load''. This, in turn may require selective adding of new debugging code, so that excessively verbose, generic logging does not degrade performance and thus produce biased results. Maximum performance tests don't have this requirement, as they only need minimal logging. 18 Identification of performance bottlenecks requires plotting resource consumption, e.g. ''memory usage'' and ''processor load''. This, in turn may require selective adding of new debugging code, so that excessively verbose, generic logging does not degrade performance and thus produce biased results. Maximum performance tests don't have this requirement, as they only need minimal logging. In addition, spotting and debugging configuration errors requires collecting information about OpenVPN's state on the client side. 18 19 19 20 There are further requirements, depending on the test environments being used; see below for details. 20 21 21 = Throughput tests = 22 = Test cases = 23 24 Here we should have a high-level list of test cases. Technical details (e.g. OpenVPN client configuration files) can also be attached. Mattock can then convert these descriptions into Fabric code which makes the magic happen. 25 26 == Throughput tests == 22 27 23 28 There are a number of factors affecting throughput: … … 34 39 There are a few specific questions that need an answer: 35 40 36 * Throughput using IPv4 code 37 * Throughput using IPv6 code 38 * Throughput using OpenSSL 39 * Throughput using PolarSSL 41 * Maximum throughput using various parameters 40 42 * MTU settings and throughput 41 43 * How does (excessive) packet loss affect performance? … … 44 46 * Other questions, which? 45 47 48 Below is a list of proposed test cases. All bandwidth (BW) numbers are in MB/s (megabytes per second). 49 50 ||'''Test name'''||'''Min clients'''||'''Max clients'''||'''BW/client'''||'''Bandwidth rise'''||'''Description'''||'''Measures'''|| 51 ||TP-1||1||10||100||Gradual||Few clients with high bandwidth||Max average throughput per second|| 52 ||TP-2||10||100||10||Gradual||Many clients with medium bandwidth||Max average throughput per second|| 53 54 Each test will be repeated for the following combinations: 55 56 ||'''IPv4'''||'''IPv6'''||'''OpenSSL'''||'''PolarSSL'''||'''Test results'''|| 57 ||X|| ||X|| ||n MB/s|| 58 ||X|| || ||X||n MB/s|| 59 || ||X||X|| ||n MB/s|| 60 || ||X|| ||X||n MB/s|| 61 62 46 63 Obviously the goal is to identify poorly performing parts of the code (if any) and improve them. 47 64 48 = Connection tests=65 == Connection tests == 49 66 50 67 Connection tests are aimed at identifying bottlenecks during spikes of (re)connection initiations, e.g. when 100 clients try to connect to the server simultaneously. … … 126 143 127 144 The ''README'' file contains everything you need to know. At least initially patches should be sent to samuli at openvpn and net, or to ''mattock'' who hangs around at #openvpn-devel on the Freenode IRC network (irc.freenode.net). 128 129 = Test cases =130 131 Here we should have a high-level list of test cases. Technical details (e.g. OpenVPN client configuration files) can also be attached. Mattock can then convert these descriptions into Fabric code which makes the magic happen.