网站Web服务器测试及优化参考_specweb测试优化

万物皆可测量，这条定律同样适用于我们经常打交道的各种服务器和应用系统。

服务器选型、测试、优化都是一些长期复杂的工作，如何在TurboCMS的项目中快速满足客户需求，我们只需要掌握以下的一些知识要点即可

1. 选型

选型一般借助于公共机构的评测数据及互联网上的参考标准

1.1服务器的选型

服务器的选型主要依据客户的需求和预算，主要涉及如下几个指标：

CPU、内存、网卡、硬盘

而网卡和硬盘的配置大多对客户需求来说绰绰有余，所以对性能指标影响最明显的就是CPU和内存

目前对服务器的主流评测机构有两家：

1.TPC(Transaction processing Performance Council,事务处理性能委员会)

2.SPEC(the Standard Performance Evaluation Corporation标准性能评估机构)

会有专门的网站给出各种服务器的评测结果，可以用作参考

针对TurboCMS的Web应用，我们主要依据TPC-W和SPECweb的评测结果

1.2操作系统的选型

TurboCMS.Java是跨平台的应用，支持Windows和Linux两种操作系统

如果是中小型网站，推荐使用Windows操作系统，易于管理

如果是大型网站，推荐使用Linux操作系统

1.3Web服务器软件的选型

目前主流的Web服务器(不包括J2EE服务器)有如下几种：nginx,apache,IIS等等

如果是Windows操作系统，可直接使用IIS

如果是Linux操作系统，可以使用nginx(推荐)或者apache

1.4J2EE应用服务器软件的选型

目前主流的J2EE服务器有：Tomcat,Weblogic,Websphere,oc4j,glassfish等等

前面的选型都不复杂，这里J2EE服务器性能也有可以参考的指标：

SPECjbb(SPEC委员会Java基准测试程序)

目前最新的评测标准是SPECjbb2005

2. 测试

测试需要借助一些主流的测试工具

2.1网站html页面的测试

TurboCMS系统需要针对不同的网站制作模板，前提是先设计好一套html，html是不是写好了，可以使用Google Page Speed这款工具测试，

以下是Google Page Speed的简要操作步骤，详细步骤请到网上自行搜索

这里是下载地址：

http://code.google.com/intl/zh-CN/speed/page-speed/download.html

这款工具是运行在Firefox下的，首先需要安装FireFox插件FireBug，下载安装后，打开FireBug，FireBug的操作界面上就会多一个选项：

打开指定的页面后，点击“Analyze Performance”，就能对当前的html进行分析，给出分数，并指出存在的问题及改进方法。

2.2网站J2EE应用的测试

可以使用LoadRunner单独录制脚本，模拟并发测试现有的J2EE(仅做性能测试)，如果是项目上定制开发的JSP，则需要请专业测试人员做功能测试和性能测试。LoadRunner的简要使用方法见下节

2.3网站整体压力测试

可以使用LoadRunner压力测试工具测试制作完毕后的网站整体页面，尽量在接近真实的环境下进行测试，LoadRunner与服务器之间的带宽尽量不要出现瓶颈。

以下是LoadRunner的简要操作步骤，详细使用方法请到网上自行搜索

LoadRunner打开后，主界面上显示三个功能链接，表示一个完整的测试分三步走

1. 创建/编辑脚本

点击“Create/Edit Scripts”，在弹出界面上选择Web项目测试

输入要录制的网站地址：

系统便会弹出录制窗口，开始录制，使用浏览器访问想要施压的页面，录制窗口便会自动记录相应的事件。如果有些事件不需要，可以在录制完毕后，从脚本里删除

通常我们会录制所有一级页面，尽量真实的模拟用户访问网站的过程

编辑完毕后，保存脚本，关闭脚本编辑器，则可开始下一步运行压力测试

2. 运行压力测试

点击“Run Load Tests”，在弹出的窗口中选择我们之前录制好的脚本

然后在任务编辑界面，调整我们需要的并发用户数，压力时间

双击这里可以直接编辑。

根据Web服务器的配置情况，我们一般从50vu开始，然后是100,150,200……

直到响应时间超过了用户可以承受的范围，或者响应时间曲线出现较大不合理波动

通常前端使用Nginx，页面数小于10用户数小于400vu的情况下，LoadRunner不会报错，如果LoadRunner报错，则检查服务器上的日志，查找原因

3. 分析压力测试

测试完毕后，即可分析测试，点击“Analyze Load Tests”，系统会自动生成报告图表，并可以选择输出测试结果为word或者html

3. 优化

优化需要借助监控工具，返回系统的状态找到系统的瓶颈，然后修改参数

3.1操作系统的优化

这里的操作系统优化主要是针对Linux，我们可以借助Spotlight on Unix这款工具监控操作系统

Spotlight可以给管理员提供一个直观的图形化界面，系统的瓶颈一目了然

监控时，先要向对应的目标服务器建立一个连接，Spotlight默认禁用了root帐号连接Linux，所以需要事先在系统中添加一个用户

如果系统中出现瓶颈，Spotlight会自动报警, 出现了警告信息后，请自行到网上搜索解决办法

操作系统的主要瓶颈通常在于应用程序允许打开的文件数，如果出现Too many open files错误，请

修改/etc/security/limits.conf

在文件最末尾添加* - nofile 965355

设置系统允许打开的文件数量，注意，这个数值不能超过100w，否则系统无法登陆

3.2Oracle数据库的优化

我们可以借助Spotlight on Oracle工具监控数据库

Oracle监控与Spotlight on Unix类似

Oracle的优化中涉及到两个关键参数processes以及sessions

分别表示Oracle的进程数和会话数，sessions=processes*1.1+1

如果是Oracle出现了瓶颈，则修改processes

注意，同样这个数值也不要轻易改变，数值是Oracle根据服务器的性能调整的结果，如果设置过大，会导致系统不稳定

3.3Web服务器软件的优化

这里的Web服务器软件主要是针对Nginx，我们可以根据LoadRunner压力测试得出的结果，以及Nginx自身产生的日志信息，来调整Nginx参数

worker_processes 8;

nginx进程数，建议按照cpu数目来指定，一般为它的倍数。

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000

01000000 10000000;

为每个进程分配 cpu，上例中将 8 个进程分配到 8 个 cpu，当然可以写多个，或者将一

个进程分配到多个cpu。

worker_rlimit_nofile 102400;

这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文

件数 （ulimit -n） 与 nginx进程数相除， 但是nginx分配请求并不是那么均匀， 所以最好与ulimit

-n的值保持一致。

use epoll;

使用epoll的 I/O模型。

worker_connections 102400;

每个进程允许的最多连接数，理论上每台 nginx 服务器的最大连接数为

worker_processes*worker_connections。

keepalive_timeout 60;

keepalive超时时间。

总结

1. Web服务器的性能调整是一个综合指标，不可能当作某个程序上的bug来处理，服务器的整体性能牵涉到服务器上的各种软硬件环境；

2. Linux环境下，各种配置参数配置完，一定要对比验证一下配置是否生效了，只有使用排除法才能避免问题的复杂化；

3. 有J2EE应用的网站，在大并发情况下，数据库是一个很大的瓶颈，需要特别注意；

4. 前端Web服务器的日志输出也是很重要的环节，在大并发下，一定要去掉日志输出，防止对性能的影响；

5. 测试环境很重要，能够在第一时间给出数据，与生产环境做出比较，就能判断错误的方向。