8.表现比较 | 8. Performance comparison
8.1编码器/解码器的比较
Megaco / H.248标准定义了纯文本编码和二进制编码（ASN.1 BER），并且我们实现了两者的编码器和解码器。我们确实提供了一堆不同的编码/解码模块，用户实际上可以实现自己的模块（比如我们的erl_dist模块）。使用非标准编码格式有明显的缺点，但在某些配置中可能会有用。
为了比较我们的不同编码器/解码器，我们对Megaco / H.248协议栈的Erlang / OTP实现进行了四次不同的测量。下表总结了每个结果。
以上结果是每个编解码器配置中速度最快的。提供的数字是所有使用的消息的平均值。
为了进行比较，还包括首先，megaco（包括测量软件）的性能数据和asn1应用程序hipe-compiled（时间列中的第二个数字，注意每个bin解码有一些问题，所以这些数字不包括在内），第二个，Flex驱动程序构建为non-reentrantflex的性能数字（时间列中的第三个数字，仅适用于使用flex-scanner的文本编解码器，括号内的数字）。
编解码器和配置 | 大小 | 编码 | 解码 | 总共 |
|---|---|---|---|---|
pretty | 336 | 20 / 13 | 75 / 40 | 95 / 53 |
pretty flex | 336 | 20 / 13 / 20 | 39 / 33 / 38 | 59 / 46 / 58 |
compact | 181 | 17 / 10 | 62 / 35 | 79 / 45 |
compact flex | 181 | 17 / 10 / 17 | 37 / 31 / 36 | 54 / 41 / 53 |
per bin | 91 | 60 / 29 | 64 / - | 124 / - |
per bin driver | 91 | 39 / 24 | 42 / 26 | 81 / 50 |
per bin native | 91 | 45 / 21 | 48 / - | 93 / - |
per bin driver,native | 91 | 25 / 15 | 27 / 18 | 52 / 33 |
ber bin | 165 | 32 / 19 | 38 / 21 | 70 / 40 |
ber bin driver | 165 | 32 / 19 | 33 / 20 | 65 / 39 |
ber bin native | 165 | 17 / 11 | 25 / 13 | 42 / 24 |
ber bin driver,native | 165 | 17 / 11 | 17 / 12 | 34 / 23 |
erl_dist | 875 | 5 / 5 | 10 / 10 | 15 / 15 |
erl_dist megaco_compressed | 405 | 6 / 4 | 7 / 4 | 13 / 8 |
erl_dist compressed | 345 | 47 / 47 | 20 / 20 | 67 / 67 |
erl_dist megaco_compressed,compressed | 200 | 34 / 33 | 11 / 9 | 45 / 42 |
8.2系统性能特性
这主要是一种使用可重入的挠性扫描仪而不是不可重入的效果的方法。
从上面的数字可以看出，当涉及到单个消息的解码时间时，不可重入和可重入的挠性扫描器之间并没有真正的区别。
真正的区别在于系统特性，最好用mstone1测试显示。
在多核计算机上运行SMP erlang时，“吞吐量”要高得多。mstone1测试是一个极端测试，但它显示了使用可重入柔性扫描仪所获得的成果。
图8.1：mstone1.sh-d flexs-s4的MStone 1
8.3编码器/解码器说明
在Megaco / H.248规范（RFC 3525）的附录A中，大约有30条消息显示了具有代表性的呼叫流程。我们还添加了一些额外的版本1，版本2和版本3消息。我们使用这些信息作为我们测量的基础。我们的数据还没有被加权，关于在媒体网关和它的控制器之间发送的不同类型的消息的频繁程度。
测试比较下列编码器/解码器：
- pretty - 漂亮的印刷文字。在文本编码中，协议栈实现者可以选择使用短和长关键字的组合。也可以添加空格以提高可读性。漂亮的文本编码利用长关键字和缩进样式，如Megaco / H.248规范中的文本示例。
- compact - 紧凑的文本编码使用尽可能短的关键字并且没有可选的空格。
- ber - ASN.1 BER。
- per - ASN.1 PER。不作为有效的Megaco / H.248编码进行标准化，但由于其编码非常紧凑，因此完整性包括在内。
- erl_dist - Erlang的原生分布格式。未被标准化为有效的Megaco / H.248编码，但由于其众所周知的性能特征而被纳入作为参考。 Erlang是一种动态类型语言，任何Erlang数据结构都可以使用内置函数序列化为erl_dist格式。实际编码的消息已按每种编码类型收集到一个目录中，每个编码消息包含一个文件。以下示例的短信息，让人感受到短信的精美版本和紧凑版本之间的区别。首先是带有长关键字的精美印刷版，缩进版：MEGACO / 1 [124.124.124.222]
??Transaction = 9998 { Context = - { ServiceChange = ROOT { Services { Method = Restart, ServiceChangeAddress = 55555, Profile = ResGW/1, Reason = "901 MG Cold Boot" } } } }
然后紧缩文本版本没有缩进和短的关键字：！/ 1 [124.124.124.222] T = 9998 {
??C = - {SC = ROOT {SV {MT = RS，AD = 55555，PF = ResGW / 1，RE =“901 MG冷启动”}}}} 8.4设置测量已在HP xw4600工作站上执行， （R）Core（TM）2 Quad CPU Q9550 @ 2.83GHz，具有4 GB内存并运行Ubuntu 10.04 x86_64，内核为2.6.32-22-generic。软件版本是开源的OTP R13B04（megaco-3.14）.8.5总结在我们的测量中，我们看到ASN.1 BER和紧凑文本格式之间的消息大小没有显着差异。在使用漂亮的文本样式（在协议规范中包含的所有示例中都使用该样式并且在调试会话期间首选时）时应该注意一些问题，因为消息可能非常大。如果消息的大小确实是一个严重的问题，那么我们应该使用每个编码器，因为ASN.1 PER格式比所有其他选择更紧凑。它的主要缺点是它没有被批准为有效的Megaco / H.248消息编码。当谈到纯粹的编码/解码性能时，事实证明：
- 我们最快的二进制编码器（ber）大约等于我们最快的文本编码器（紧凑型）。
- 我们最快的二进制解码器（ber）比我们最快的文本解码器（紧凑型）快大约54％（61％）。
如果纯粹的编码/解码性能确实是一个严重的问题，我们可以使用erl_dist编码器，因为erlang分布格式的编码/解码比其他所有方法快得多。它的主要缺点是它没有被批准为有效的Megaco / H.248消息编码。
在可重入柔性扫描仪上构建（并使用）非重入式柔性扫描仪（如果Flex支持构建这样的扫描仪），没有性能优势。
注
请注意，这些性能数据与我们在Erlang / OTP中的实现有关。使用其他工具和技术的其他实现的测量当然可能导致其他数字。
本文档系腾讯云开发者社区成员共同维护，如有问题请联系 cloudcommunity@tencent.com
