龙芯2F平台Web性能测试报告.docx

龙芯2F平台Web性能测试报告.docx

《龙芯2F平台Web性能测试报告.docx》由会员分享，可在线阅读，更多相关《龙芯2F平台Web性能测试报告.docx（25页珍藏版）》请在冰豆网上搜索。

龙芯2F平台Web性能测试报告

龙芯2F平台Web性能测试报告（下）

来源：

计算机世界实验室作者：

韩勖发布时间：

2008-08-13

　　上期我们发布的龙芯2F平台Web性能测试报告引起了广泛关注，许多热心读者通过各种方式向我们表达了自己的看法与建议，在此表示感谢。

一些读者也指出，单凭静态页面的处理能力评估处理器和硬件平台，并不具备完整性。

的确，在这个Web2.0大行其道的时代，静态页面的应用范围越来越小，这是无可争议的事实。

本次测试的下半部分，我们就通过3个相对复杂的测试用例，考察了两个硬件平台承载动态页面时的性能。

　　动态页面的基础是对象脚本语言和数据库，我们首先要做的是搭建一个满足需求的测试环境。

在之前的测试中，两个平台都已装好Linux和Apache，实验室工程师直接在此基础上安装了PHP和MySQL，构建了一个完整的LAMP（Linux/Apache/MySQL/PHP）环境。

以高性能、低成本著称的LAMP是当前主流的开发和应用环境之一，我们也希望这次测试能为诸多开源平台下的开发者和用户带来帮助。

考虑到基于PHP的应用中经常涉及到对图像的处理，我们也安装了GD库的所有组件，并建立了必要的关联。

　　测试环境搭建完成，接下来就是应用环境和测试用例的选择。

对此，实验室工程师的原则是，既能充分考察硬件平台的性能，又要具备实用性和代表性。

应用环境的最终选择是Discuz！

网络论坛，它有足够多的部署基础，程序结构和算法又相对复杂，操作模型也便于测试仪实现。

基于它我们可以打造很多与实际应用紧密关联的测试用例，通过考察HTTP最大新建连接能力，全面地反映出被测平台的Web性能。

　　Discuz！

（6.0.0_SC_UTF8）的安装过程很简单，并且安装完毕后的默认配置已经在保证兼容性的前提下对性能进行了优化。

工程师很快就在两个平台上成功搭建出新论坛，虽然只有一个用户、一个默认板块并且从未发表过帖子，但论坛首页的正常显示意味着LAMP四大组件已经全部处于带负载的工作状态。

这个首页就是我们第一个测试用例，龙芯平台每秒最大可以处理11个访问请求，而对比平台则可以处理20个。

　　打开论坛的验证码模块，利用GD库实时生成图片验证码，增加处理器运算单元的负担，是我们计划中的第二个测试用例。

但在实施过程中，我们发现Discuz！

为提高运行效率，只有在使用鼠标点击验证码输入框时，才会生成随机验证码图片，而测试仪很难模拟这个行为。

程序的复杂结构为代码分析制造了很大障碍，我们最终放弃了寻找并提取功能模块的想法，转而在首页的源文件中编写了一段原理、功能相似的代码作为替代。

这一次，龙芯平台每秒最大事务处理能力降到9，而对比平台则降为16。

　　从降幅中可以看出，通过GD库输出随机验证码图片对处理器造成的负载并不大，大量资源被论坛复杂的脚本解析和数据库操作所占用。

为了证明这一点，我们把刚才编写的代码单独保存成一个脚本进行了测试，即第三个测试用例。

龙芯平台每秒最大可以处理43个访问请求，而对比平台的每秒最大事务处理能力则高达104，与之前的推测相吻合。

　　整理一下三次的测试数据，发现一个很有意思的情况。

从脚本的复杂程度来说，随机验证码图片的生成最简单，论坛首页次之，两者结合最复杂，这也可以从两个平台测试成绩的纵向比对中被证明。

再横向比对一下，单独考察随机验证码图片的生成，龙芯平台的性能约为对比平台的41%；单独考察论坛首页，龙芯平台的性能是对比平台的55%；而在两个测试用例相结合的情况下，龙芯平台性能约为对比平台的56%。

脚本越复杂，两个平台的性能差距越小。

　　我们推断，造成这种情况的罪魁祸首主要是处理器流水线级数的差异。

处理的事务模型越复杂，中断流水线操作的可能性就越大。

而事务模型相同的情况下，流水线越长，中断流水线操作的代价就越大。

Northwood核心的Celeron处理器流水线高达21级，是龙芯2F的两倍多，也就不难理解为何测试脚本越复杂，两个平台的性能差距越小。

如果有机会，我们一定找一颗31级流水线的Prescott核心Celeron处理器来验证这个推断。

　　客观地讲，龙芯2F平台在测试中的综合表现是基本令人满意的。

静态页面的处理能力体现出I/O、缓存等架构方面的先进性；动态页面的测试结果表明运算单元的性能还有待提高，这可以通过提高频率等方式解决。

物理特性是优势所在，低功耗带来了低发热，在恒温28度的实验室环境下，龙芯处理器连续满载工作24小时后散热片温度仅为57度，被动散热就足以满足需求，环境适应性比较突出。

　　随着应用范围的逐步扩展，我们认为龙芯要优先解决的已不再是处理器的问题，而是编译器的问题。

对于通用处理器来说，一个适用的编译器不但可以最大限度地发挥硬件平台的性能，更可以有针对性地弥补某些性能弱项。

应用层面越高，这一点越重要，毕竟处理复杂事物时影响性能的关键因素就是最短的那块木板。

　　缺乏自己的编译器，这个问题已经开始制约龙芯平台性能的发挥。

我们注意到，ST在相关文档中提到龙芯2F处理器已具有类SSE形式的SIMD指令集，没有相应的编译器，又如何能让这些指令发挥作用？

进一步讲，如果通用编译器现在还基本能发挥龙芯2号处理器的性能，又能让即将面世的龙芯3号多核处理器发挥出多少性能呢？

如果那个时候才开始做相应的工作，恐怕为时已晚。

在4月份刊发的龙芯2E防火墙评测报告中，我们特别提到对龙芯发展方向的看法，那就是远离注重直观体验的桌面应用，进军服务器、网络通信与信息安全等领域，尽量弱化指令集、系统架构、操作系统和上层软件差异带来的影响。

近日，实验室拿到了一套完整的龙芯2F开发套件，我们按照上面的想法搭建成Web服务器，重点考察了产品做Web应用时的效能。

　　在应用模式趋于多样化的今天，处理器的绝对性能已变得不那么重要，应用环境下的性能逐渐为人所重视。

这次我们选择考察Web服务的应用效能，走的正是一条理论与实际相结合的道路。

处理器在响应外部HTTP请求时，会消耗一定的资源。

一旦超出处理能力，连接请求就会得到各种错误响应。

通过测试每秒钟不含错误的最大成功建立连接个数，可以比较准确地评估处理器或硬件平台的性能，为基于平台的真实应用提供参考，这就是计算机世界实验室一直以来针对服务器产品的评测思路。

　　寻找一个合适的对比平台，是本次测试最具难度的任务之一。

业内关于龙芯产品的评测报道极少，800MHz的龙芯2F性能到底如何，谁心里都没底。

我们希望能够找到一个性能与之相仿的硬件平台，将测试结果进行合理的对比分析。

工程师几乎检视了实验室所有的PC与服务器，最后决定用一台配有IntelCeleron2.1GHz处理器的联想启天M2200作为对比平台——尽管我们推测1.8GHz左右的P4平台可能会比较合适，但这已经是我们能找到的配置最低的主机了。

　　相比之下，软件环境的搭建就显得容易的多。

两组平台都基于Linux，其中龙芯2F开发套件的硬盘中已安装好了较为常见的Debian，附带有被广泛应用的Web服务端软件Apache2。

实验室工程师在对比平台上安装了Ubuntu8.04ServerEdition，并在命令行下通过网络安装好最新版的Apache2。

我们努力让龙芯平台与对比平台软硬件配置相似，最大程度地减少了影响测试准确性的因素。

　　我们使用思博伦通信提供的Avalanche2500测试了两组平台的新建连接性能，脚本采用8字节的静态页面，避免因数据传输或网络带宽限制影响测试结果。

Apache2提供了实现机制迥异的多路处理模块，用以实现端口监听、请求处理等功能，其中以基于进程的prefork和进程、线程混合的worker比较有代表性。

考虑到可能造成的性能差异，我们分别在这两种模式下进行了测试。

　　首先是prefork模式，龙芯平台每秒新建连接数达到1582个，而对比平台为1121个。

虽然处理器的频率和真实效能间没有直接联系，但800MHz的龙芯2F超越了2.1GHz频率的Celeron，是我们没有想到的。

而worker模式下龙芯平台每秒新建连接数为1289个，虽然依旧领先于对比平台1068个的表现，但幅度校prefork模式下下降很多。

两个平台下worker模式性能都低于prefork模式，这很难解释。

由于采用了更先进的处理机制，理论上前者的性能应优于后者，我们推测龙芯2F与Celeron这类单核、单线程处理器并不利于采用进程、线程混合机制的worker模式运行。

　　考察项目还包括两组平台在空载与满载时的功耗情况，涉及到的部件包括处理器、主板、内存、网卡和一块硬盘。

龙芯平台加电进入系统后空载待机功耗为32W，满载时功耗保持不变；对比平台加电进入系统后空载待机功耗为41W，满载时功耗上升到71W。

这个结果要从两方面看。

一方面，刨除硬盘自身7-8瓦的功耗，龙芯2F开发板上的组件功耗只有二十多瓦，确实有优势；另一方面，空载满载时的功耗相同，意味着龙芯2F处理器还没能实现对功耗进行动态控制。

Intel处理器这方面做的就很到位，我们注意到从加电到进入系统的过程中，对比平台的功耗一直在60-70W之间浮动；而完全进入系统后，功耗马上降低至41W。

　　处理器本身功耗低并不意味着就可以忽视这一特性。

经过与计算所方面的反复核实，我们得知龙芯2F处理器已经在硬件上具备了根据负载动态调节功耗的能力，只是尚未在软件层面实现。

感觉不止是这一方面，龙芯平台在软件层面上还有太多需要完善的东西，例如64位操作系统、编译器的优化、软件代码的优化等，都是可以有效提高性能的手段。

计算所作为龙芯处理器的研发机构，纵然不能独自完成这些工作，也应该努力推动产业内不同角色的公司、机构参与进来，共同完善龙芯平台的软硬件环境。

　　时间所限，本次我们并没有完成更多的测试项目。

计算机世界实验室将继续对龙芯平台进行Web服务的应用测试，引入涵盖动态页面与数据库操作等内容在内的复杂脚本，全面

龙芯2F处理器GCC4.4优化探秘

标签：

龙芯 2008-10-2113:

52

来源：

计算机世界实验室作者：

韩勖发布时间：

2008-10-21

　　作为Linux平台下最常用的编译器，GCC提供了强大的编译能力和良好的平台通用性，其重要性不言而喻。

编译优化是它的一大特点，除了可以对软件代码进行不同程度的分析优化外，GCC还可以根据处理器的结构特性在编译中对代码进行有针对性的编排组合，以更加高效地运行于目标平台。

目前，处在最后测试阶段的GCC4.4加入了针对龙芯处理器的编译优化支持，配套文档中也给出了详细的操作说明。

针对这一改进，计算机世界实验室于近日进行了一次特别测试，重点研究GCC4.4为龙芯平台软件环境带来的性能提升。

　　测试的软件环境基于3个在龙芯平台上比较常见的操作系统构建，分别是Debian、Gentoo与国产的Linux操作系统“憨牛”。

前两者是在世界范围内得到广泛应用的Linux发行版，都拥有独立的软件包管理系统和海量的应用软件。

它们的软件包管理模式存在差异，Debian为多种硬件架构提供了编译好的二进制包，为最大程度地保证兼容性，MIPS架构的二进制文件采用最基础的MIPS1指令集架构编译；Gentoo则提倡源代码发行的方式，安装软件时对下载的代码进行本地编译。

利用上述特性，我们分别用Debian和Gentoo构建了针对MIPS1和针对龙芯2F、o32模式编译的测试环境。

而“憨牛”是国内龙芯爱好者以LFS方式制作的纯64位发行版，我们用它作为龙芯2F、n64模式下的测试环境。

这些系统都被安装在硬盘的不同分区中，并将内核统一指定为Server模式的2.6.26.5，编译参数采用“-march=loongson2f-mabi=n64-O3”。

为保证结果的一致性，我们选择截止到测试开始前的最新版本“GCC4.4snapshot20080923”作为统一使用的编译器。

如无特别标识，所有测试软件均使用“-O2”参数进行编译。

　　为了让测试结果更具普遍性，本次测试的硬件平台也由开发板换成中科龙梦推出的福珑2F-6003迷你电脑。

这款产品虽然只有普通光驱的大小，却内置了龙芯2F800MHz处理器、DDR2-533512MB内存和80GBUltraATA2.5英寸硬盘。

板载的RealtekRTL8110SC网络控制器则提供了一个千兆以太网接口，为网络应用做好准备。

这款产品配备了一个输出功率为40W的变压器，但在我们的测试中实测功耗从未超过15W。

因为低功耗、低噪音等特性，很多用户都将福珑2F-6003当做不掉电的下载机或SOHO服务器使用。

理论性能测试

　　LMbench是一款历史悠久的性能评测工具，被广泛应用于UNIX/Linux环境下的系统性能评估。

它包含了一系列测试程序，可以对不同层面、不同子系统进行专项测试。

随着应用模式的变化，新版本的LMbench中也不断加入有针对性的测试程序，保持了评估模型的准确性。

本次我们采用了LMbench最新的3.07a版，利用其中附带的lat_ops和par_ops两个程序，测试不同指令集版本、处理器类型及ABI模式下指令执行的相关性能，从而考察GCC4.4对龙芯2F处理器的支持程度。

作为对比，我们也将源代码编译为匹配MIPS1指令集与MIPSR4600处理器的版本进行了测试。

前者是目前支持MIPS的Linux二进制发行版使用的编译模式，后者是中科龙梦在GCC4.4发布前官方建议的优化设置。

　　lat_ops的功能很简单，就是考察对不同变量类型执行操作所需的时间。

可以看到，即使针对龙芯2F和R4600处理器进行优化，很多操作所需要的时间也与按MIPS1指令集架构编译后的成绩相差无几。

变化主要发生在对64位整型变量的操作方面，测试程序针对龙芯2F与R4600编译后的运行速度普遍有所提高，各别测试结果发生了数量级上的变化。

在对64位整型变量进行整数除法与取余数操作时，n32与n64模式下执行速度提高4倍，体现了不同ABI的差异。

基本可以认为，对于lat_ops所测试的指令，GCC4.4针对龙芯2F和R4600处理器进行编译的效果相仿，二者均略优于MIPS1。

　　与lat_ops相比，par_ops更像是一个进阶测试。

通过对前者的修改与扩展，par_ops着力于体现处理器在指令层面的并行处理能力。

它使用了一些类似教科书上讲述并行计算时采用的示范代码，只要处理器与编译器支持，就可以以并行方式同步执行，其结果反应了每指令周期不同操作达到的并行度。

这部分的测试结果比较混乱，除了一些并行度相同的操作外，很难在其他项目中寻找一个线形的变化规律。

纵向的比较反而更容易说明问题，o32模式和针对MIPS1指令集架构编译的代码并行度相对较低，n32模式下针对R4600处理器编译的代码则在很多操作中拥有最高的并行度。

GCC4.4对龙芯2F处理器的优化能力似乎还有提升的空间，虽然n64模式下针对龙芯2F编译的代码执行并行度最高，但在o32和n32模式下，对浮点型变量的操作并行度与R4600还有明显差距。

　　总体来说，在指令层面，使用GCC4.4针对龙芯2F进行优化编译的效果还是比较明显的，这一点在64位环境下尤为突出。

我们还使用-O2与-O3参数分别编译了针对龙芯2F、n32模式优化的代码，考察两者之间的性能差异。

也许是测试程序的代码太过简单，lat_ops与par_ops靠进一步优化获得的性能提升与编译增加的时间绝不成正比。

实际应用测试

　　接下来进行的实际应用性能测试相信更让人感兴趣。

根据现有测试条件，我们选取了一些比较常见的应用作为测试项目，并将它们归纳为桌面与网络两大类。

桌面部分包括病毒检测、压缩打包和音频编码三种应用，考量指标是完成任务需要的时间；网络部分则通过在不同系统环境下构建完整的LAMP（Linux/Apache/MySQL/PHP）服务，使用思博伦通信的Avalanche2500应用层性能测试仪考察不同测试用例的每秒最大新建事务数。

　　病毒检测软件选用的是比较著名的ClamAV，引擎与特征库统一为测试当天的最新版本。

测试用例是一个保存Windows系统下绿色软件的文件夹，内含52个子文件夹，共816个文件，大小为121MB。

为加大负载，我们还将此文件夹在Windows下用WinRAR压缩为61.4MB大小的Zip格式文件，执行病毒检测时多了动态解压缩的步骤。

从测试结果可以看出，针对龙芯2F、o32模式编译的代码与针对MIPS1指令集架构编译的代码执行效率相仿，后者的综合成绩还略好些；n64模式下的病毒检测速度相对较慢，看来ClamAV涉及到的计算模型并不能从纯64位环境中获益。

　　压缩打包测试直接利用了上面的测试用例。

我们在bash下通过tar调用gzip，将文件夹打包成一个文件，并记录任务完成所用的时间。

在这一环节，64位环境同样没有给应用带来性能提升。

针对龙芯2F、o32模式编译的代码执行速度最快，领先MIPS1编译版本十几个百分点，应当是指令集与指令调度方面的原因。

　　音频编码的性能差异是实验室工程师最感兴趣的地方。

根据以往的测试经验，这也是最能体现架构与指令集进步的部分。

除了运算单元的改进，SIMD指令也有可能显著提高编码性能，但这一切都要通过优秀的编译器和适当的算法（代码）联合实现。

本次测试我们采用的是著名的MP3编码软件LAME，目标对象是一个131MB大小、16位/44.1KHz的WAV文件，编码参数均为默认设置。

可以看到，GCC4.4针对龙芯2F的编译优化首次起到决定性的作用，即便最慢的o32模式的执行速度也比针对MIPS1指令集机构编译的代码快近50%。

为弄清性能提升的主要原因，我们特别编译了一个版本进行对比：

针对R4600处理器、n32模式编译的LAME完成编码工作共耗时252秒，看来性能提升的主要原因是使用了MIPS3指令集；而与龙芯2F、n32模式下超过1/10的性能差异，则可能源于不同的指令调度模型和SIMD指令。

通过这项测试，我们推断音、视频编解码软件是最值得通过编译优化的一类程序，它们的性能很可能从GCC4.4中得到质的提升。

　　为保持评估标准的一致性，我们在网络应用性能测试中沿用了先前的测试方法与测试用例。

从结果来看，64位系统环境终于带来了性能提升，各项测试成绩均为第一。

针对MIPS1指令集架构编译的LAMP环境表现也令人惊讶，在涉及动态页面解析的测试项中达到了与龙芯2F、n64模式相同的性能。

同样是o32，针对龙芯2F编译的LAMP环境则有些令人失望，其表现出来的性能在本次测试中垫底。

　　从静态页面的测试结果中可以看出，针对龙芯2F、o32与MIPS1编译的两组环境成绩近乎一致，而针对龙芯2F、n64模式编译的环境性能高出一筹，说明前两者的瓶颈在于o32这种ABI而非内核或编译Apache时指定的指令集。

当测试用例转向复杂的动态页面，所有平台都无法突破11/9/43这一成绩，也许这就是处理器的极限？

我们测试过的龙芯2F开发板配备了与福珑2F-6003相同的处理器和频率高出13%的内存，结果也只是静态页面处理能力得到小幅提高。

　　比起桌面应用，LAMP服务环境相对复杂的多，与内核的关联也更加紧密。

这部分我们进行的颇为周折，起初因为各系统环境的内核抢占模式不统一，导致测试结果没有可比性，只能全部复测。

不过，这也是第一次通过测试验证了内核几种抢占模式下的特征差异，为选择提供了依据。

　　做网络应用时，使用Server参数编译的内核状态最为稳定，可以准确找到系统的最大新建事务数，再此基础上哪怕多一个连接请求都会导致访问失败，并且多次测试的复现率可以达到100%。

使用Desktop参数编译的内核稳定性稍差，只能将最大新建事务数锁定在一个比较小的范围，且很难通过复测找到一个准确值。

我们在这种内核搭配针对龙芯2F、n64模式编译的LAMP环境下，只能将静态页面的新建能力锁定在1200/1180±50这一区域。

而使用Low-LatencyDesktop参数编译的内核，在搭配针对龙芯2F、o32模式编译的LAMP环境下只能稳定取得一个1100/1050的成绩。

如再增加连接请求，非但每一次测试结果都不相同，成功访问事物的响应时间也会出现较大抖动。

看来，支持抢占模式的内核虽然大大提升了图形界面下操作的响应时间，却不太适合做网络应用。

尤其像静态页面这种Web服务，事物模型简单却为数众多，负载高时抢占内核执行的空隙效果不大，还会带来不小的系统开销。

另外，根据复测得到的结果，内核抢占模式的设定对之前在命令行下进行的单任务测试几乎没有影响。

　　因为本次测试缺少n32模式的系统环境（针对龙芯2F、n32模式编译的LAME采用静态连接），导致不能确定龙芯平台上最适合实际应用的编译参数，这一点殊为可惜。

就目前情况看，我们选择的应用软件都或多或少地从针对龙芯2F处理器的编译中获益。

依照惯例，GCC的版本由测试版变为正式版后，编译优化的性能还会有小幅提高，将在几个月内发布的GCC4.4正式版值得重点关注。

　　网络应用与桌面应用往往在运算模型方面相差甚大，受ABI的影响自然也不相同。

n64模式在网络应用和o32模式在桌面应用方面的表现值得肯定，但它们占据优势的应用又是彼此的弱势领域。

相信每个人都会想到，如果能集合o32与n64的优势就好了。

确实，我们也这样想，于是就对兼具n64与o32特性的n32模式又多了那么几分期待。

测试后记

　　这是一次艰苦的测试，我们遭遇了太多的困难。

虽然大部分问题都在测试过程中被解决，但也有一些瓶颈始终无法突破，例如实际应用部分缺乏n32模式的测试成绩，就是最大的遗憾。

事实上，在测试后期，我们对龙芯系统平台方面的关注度远远超越了GCC。

我们暂时无法找到为龙芯打造的n32系统环境，就算采用LFS的方式制作一个测试专用版本，也绝非一件容易的事情。

不过通过这次测试，工程师对目前龙芯平台上可运行的系统有了初步了解。

他们各自有各自的特色，用户最好根据实际情况进行选择。

　　Debian是成熟度很高的Linux发行版，提供了对不同硬件平台的支持。

通过强大的软件包管理系统，可以很方便地下载安装针对MIPS1指令集编译的二进制包，过程简单方便，适合普通用户选用。

Gentoo的特点则是独具一格的源代码发行模式，操作者通过软件包管理系统下载软件的源代码，再在本地完成编译工作。

虽然这比直接下载二进制代码多了一个步骤，但对用户来说是透明的，并没有增加操作难度。

环境变量中编译参数的部分是关键，例如本次测试中参数设定为龙芯2F、o32，则最后得到二进制代码都是针对龙芯2F、o32模式编译的。

这种方式有助于定制特殊的软件环境，比较适合进行开发或搭建以提供服务为目的的系统平台。

不过，目前Debian和Gentoo都不算是正式支持龙芯平台的系统，只有用户群体达到一定规模，才有可能得到官方的支持。

　　福珑2F-6003预装的新华华镭操作系统倒是官方支持龙芯平台的Linux发行版，也是原本计划中MIPS1模式的测试平台。

我们在安装ClamAV时遇到了很严重的问题：

系统提示其依赖的其他软件包版本不符合要求，无法继续安装过程。

也就是说，ClamAV在华镭的软件包管理系统中存在但不可用，是一个破损的软件包。

相信类似的依赖关系问题还有不少，但维护人员和用户数量方面的原因导致问题很难被及时解决。

　　越来越清晰地感觉到，编译器之后，龙芯还剩最后一个关键问题亟待解决，那就是寻找一套功能完善、软件支持丰富、能很好地发挥硬件性能的系统环境。

从测试结果看，针对MIPS1指令集编译的二进制代码显然不能很好地发挥龙芯的性能，工作在n64或n32模式下的系统才是未来的发展方向。

新系统最好能够与Debian、Gentoo这样的发行版相融合，借助其规范体系与资源积累方面的优势，充分提高平台的易用性。

这个工作单靠研发单位的力量是很难完成的，必须在初始阶段就与开源社区相结合，