Please, observe that these performance figures are related to our implementation in Erlang/OTP. Measurements of other implementations using other tools and techniques may of course result in other figures.
The Megaco/H.248 standard defines both a plain text encoding and a binary encoding (ASN.1 BER) and we have implemented encoders and decoders for both. We do supply a bunch of different encoding/decoding modules and the user may in fact implement their own (like our erl_dist module). Using a non-standard encoding format has its obvious drawbacks, but may be useful in some configurations.
We have made four different measurements of our Erlang/OTP implementation of the Megaco/H.248 protocol stack, in order to compare our different encoders/decoders. The result of each one is summarized in a line chart:
In Appendix A of the Megaco/H.248 specification (RFC 3525), there are about 30 messages that shows a representative call flow. We have also added a few extra version 1, version 2 and version 3 messages. We have used these messages as basis for our measurements. The numbers within parentheses are the plain average values. Our figures have not been weighted in regard to how frequent the different kinds of messages that are sent between the media gateway and its controller.
The test compares the following encoder/decoders:
The actual encoded messages have been collected in one directory per encoding type, containing one file per encoded message.
Here follows an example of a text message to give a feeling of the difference between the pretty and compact versions of text messages. First the pretty printed, well indented version with long keywords:
MEGACO/1 [124.124.124.222] Transaction = 9998 { Context = - { ServiceChange = ROOT { Services { Method = Restart, ServiceChangeAddress = 55555, Profile = ResGW/1, Reason = "901 MG Cold Boot" } } } }
Then the compact text version without indentation and with short keywords:
!/1 [124.124.124.222] T=9998{ C=-{SC=ROOT{SV{MT=RS,AD=55555,PF=ResGW/1,RE="901 MG Cold Boot"}}}}
The measurements has been performed on a HP workstation xw4400 with an Intel Core 2 Duo 2.13 GHz, 3 GB memory and running SLES 10 SP1 i586, kernel 2.6.16.54-0.2.5-bigsmp Software versions was open source OTP R12B-2 and megaco-3.8 (R12B-1 and megaco-3.7.3).
This chapter details the effects of the possible encoding configurations for every codec. The result above are the fastest of these configurations for each codec. The figures presented are the average of all used messages.
For comparison, also included are performance figures for when both the test program and the codec's where hipe compiled. In the case of the binary codec's, the asn1 run-time was also inlined.
Codec and config | Size | Encode | Decode | Total |
pretty | 336 | 30 (31) | 98 (115) | 129 (146) |
pretty [flex] | 336 | 31 (31) | 53 (60) | 84 (91) |
pretty hipe | 336 | 18 (18) | 50 (58) | 68 (76) |
pretty [flex] hipe | 336 | 18 (18) | 44 (51) | 62 (69) |
compact | 181 | 26 (26) | 80 (91) | 106 (117) |
compact [flex] | 181 | 26 (26) | 49 (56) | 75 (82) |
compact hipe | 181 | 13 (14) | 45 (53) | 58 (67) |
compact [flex] hipe | 181 | 13 (14) | 39 (47) | 52 (61) |
per bin | 91 | 84 (82) | 86 (87) | 170 (169) |
per bin [driver] | 91 | 57 (57) | 58 (59) | 115 (116) |
per bin [native] | 91 | 64 (63) | 64 (63) | 127 (126) |
per bin [driver,native] | 91 | 36 (35) | 37 (38) | 72 (73) |
per bin hipe+inline | 91 | 38 (38) | 40 (38) | 78 (76) |
per bin [driver] hipe+inline | 91 | 33 (33) | 33 (36) | 66 (69) |
per bin [native] hipe+inline | 91 | 28 (28) | 30 (29) | 58 (57) |
per bin [driver,native] hipe+inline | 91 | 22 (22) | 25 (25) | 47 (47) |
ber bin | 165 | 46 (45) | 71 (70) | 116 (115) |
ber bin [driver] | 165 | 46 (45) | 51 (51) | 97 (96) |
ber bin [native] | 165 | 26 (26) | 48 (47) | 74 (73) |
ber bin [driver,native] | 165 | 26 (26) | 29 (28) | 54 (54) |
ber bin hipe+inline | 165 | 24 (24) | 41 (41) | 65 (65) |
ber bin [driver] hipe+inline | 165 | 24 (24) | 30 (30) | 54 (54) |
ber bin [native] hipe+inline | 165 | 14 (14) | 31 (31) | 45 (45) |
ber bin [driver,native] hipe+inline | 165 | 14 (14) | 20 (20) | 34 (34) |
erl_dist | 875 | 7 (7) | 13 (13) | 20 (20) |
erl_dist [megaco_compressed] | 405 | 8 (8) | 9 (9) | 17 (17) |
erl_dist [compressed] | 345 | 143 (142) | 31 (31) | 174 (173) |
erl_dist [megaco_compressed,compressed] | 200 | 119 (111) | 17 (18) | 137 (129) |
erl_dist hipe | 875 | 7 (7) | 13 (13) | 20 (20) |
erl_dist [megaco_compressed] hipe | 405 | 6 (6) | 6 (6) | 12 (12) |
erl_dist [compressed] hipe | 345 | 135 (130) | 30 (29) | 165 (159) |
erl_dist [megaco_compressed,compressed] hipe | 200 | 107 (108) | 14 (14) | 121 (122) |
In our measurements we have seen that there are no significant differences in message sizes between ASN.1 BER and the compact text format. Some care should be taken when using the pretty text style (which is used in all the examples included in the protocol specification and preferred during debugging sessions) since the messages can then be quite large. If the message size really is a serious issue, our per encoder should be used, as the ASN.1 PER format is much more compact than all the other alternatives. Its major drawback is that it is has not been approved as a valid Megaco/H.248 message encoding.
When it comes to pure encode/decode performance, it turns out that:
If the pure encode/decode performance really is a serious issue, our erl_dist encoder could be used, as the encoding/decoding of the erlang distribution format is much faster than all the other alternatives. Its major drawback is that it is has not been approved as a valid Megaco/H.248 message encoding.
Please, observe that these performance figures are related to our implementation in Erlang/OTP. Measurements of other implementations using other tools and techniques may of course result in other figures.