LR性能测试报告-WebGIS

WebGIS综合发布平台性能测试
结果报告
2012/5/17
本文档主要描述WebGIS综合发布平台性能测试结果以及分析测试结果。

第一章WebGIS性能测试概述
1.1测试目的
测试5分钟可以生成多少个专题产品工作流，建议使用多少进程运行。

测试矢量底图、影像底图可以支持多少并发用户数（响应时间在5秒内）。

建议使用多少进程运行以及并发人数。

测试前台标绘站点与后台生成站点，哪种方式更为合适。

第二章测试场景及测试环境配置
2.1测试场景网络环境拓扑
2.2测试环境配置
测试环境带宽：100Mb/s=12.5MB/s
第三章测试实施及测试结果
3.1测试工具
Loadrunner 11.0
3.2测试内容
3.2.1生成专题产品工作流
对50或100个并发用户，分别在三个进程、六个进程、九个进程、十二个进程、十六个进程的情况下，完成生成专题产品工作流，测试其完成情况以及服务器资源使用情况。

场景描述：
模拟50或100个用户并发执行生成专题产品工作流（测试站点数量大小为6790条站点数据）的请求到服务器，服务器接收请求后，执行生成专题产品工作流流程，将结果返回到客户端。

测试中的事务说明：
●Workflow：模拟50或100个用户并发执行生成专题产品工作流，完成一个workflow事务
就是完成一个工作流。

测试执行时间设置说明：
●每10秒增加5个用户，大概1分30秒之后达到50个用户（3分20秒之后达到100个用
户）。

●然后50个用户（或100个用户）并发持续执行5分钟。

●然后每10秒减少10个用户，大概8分钟之后50个用户减少到0（大概11分钟后100个
用户减少到0）。

3.2.2矢量底图与影像底图显示
对50或100或200个并发用户，分别在一个进程、三个进程、五个进程的情况下，不断执行放大、拖动、缩小操作，测试打开矢量底图与影像底图页面以及执行放大、拖动、缩小操作的平均响应时间、吞吐量、每秒点击数以及服务器性能。

场景描述：
模拟50或100或200个用户，打开矢量行政区或影像底图单图层地图页面（浏览器窗口大小为1280*520），执行放大->拖动->缩小操作。

场景中：矢量行政区数据总大小为7.29GB，影像地图总大小为60.97GB，初始化页面请求了40张图片，放大操作请求了21张图片，拖动操作
请求了26张图片，缩小操作请求了21张图片。

测试的中事务说明：
●Init：模拟50/100/200个用户打开矢量行政区或影像底图单图层地图页面。

●Zoomout：打开页面后，用户点击‘放大’按钮（从4级变为9级），执行放大地图操作。

●Move：用户执行完放大地图操作后，移动地图，执行拖动的操作。

●Zoomin：用户执行完拖动操作后，点击‘缩小’按钮（从9级变为2级），执行缩小地图
的操作。

测试执行时间设置说明：
●每10秒增加5个用户，大概1分30秒之后达到50个用户（3分20秒之后达到100个用
户，6分30秒之后达到200个用户）。

●然后50个用户（或100个用户或200个用户）并发持续执行5分钟。

●然后每10秒减少10个用户，大概到8分钟之后50个用户减少到0（大概11分之后100
个用户减到0，大概18分钟之后200个用户减到0）。

3.2.3前台标绘站点
对50或100或200个并发用户，分别在一个进程、三个进程、五个进程的情况下，不断执行放大、拖动、缩小操作，测试打开前台标绘站点页面以及执行放大、拖动、缩小操作时的平均响应时间、吞吐量、每秒点击数以及服务器性能。

场景描述：
模拟50或100或200个用户，打开矢量行政区单图层（2000或3000或5000）站点地图页面（浏览器窗口大小为1280*520），执行放大->拖动->缩小操作。

场景中：
●5000个站点初始化页面请求了40张图片，放大操作请求了21张图片，拖动操作请求了
13张图片，缩小操作请求了21张图片。

●3000个站点初始化页面请求了40张图片，放大操作请求了21张图片，拖动操作请求了
13张图片，缩小操作请求了21张图片。

●2000个站点初始化页面请求了40张图片，放大操作请求了21张图片，拖动操作请求了
10张图片，缩小操作请求了21张图片。

测试的中事务说明：
●Init：模拟50/100/200个用户打开矢量行政区或影像底图单图层地图页面。

●Zoomout：打开页面后，用户点击‘放大’按钮（从4级变为9级），执行放大地图操作。

●Move：用户执行完放大地图操作后，移动地图，执行拖动的操作。

●Zoomin：用户执行完拖动操作后，点击‘缩小’按钮（从9级变为2级），执行缩小地图
的操作。

测试执行时间设置说明：
●每10秒增加5个用户，大概1分30秒之后达到50个用户（3分20秒之后达到100个用
户，6分30秒之后达到200个用户）。

●然后50个用户（或100个用户或200个用户）并发持续执行5分钟。

●然后每10秒减少10个用户，大概到8分钟之后50个用户减少到0（大概11分之后100
个用户减到0，大概18分钟之后200个用户减到0）。

3.2.4后台生成站点
对50或100或200个并发用户，分别在一个进程、三个进程、五个进程的情况下，不断执行放大、拖动、缩小操作，测试打开后台生成站点页面以及执行放大、拖动、缩小操作时的平均响应时间、吞吐量、每秒点击数以及服务器性能。

场景描述：
模拟50或100或200个用户，打开矢量行政区单图层（2000或3000或5000）站点地图页面（浏览器窗口大小为1280*520），执行放大->拖动->缩小操作。

场景中：
●5000个站点初始化页面请求了41张图片，放大操作请求了22张图片，拖动操作请求了
25张图片，缩小操作请求了22张图片。

●3000个站点初始化页面请求了41张图片，放大操作请求了22张图片，拖动操作请求了
22张图片，缩小操作请求了22张图片。

●2000个站点初始化页面请求了41张图片，放大操作请求了22张图片，拖动操作请求了
24张图片，缩小操作请求了22张图片。

测试的中事务说明：
●Init：模拟50/100/200个用户打开矢量行政区或影像底图单图层地图页面。

●Zoomout：打开页面后，用户点击‘放大’按钮（从4级变为9级），执行放大地图操作。

●Move：用户执行完放大地图操作后，移动地图，执行拖动的操作。

●Zoomin：用户执行完拖动操作后，点击‘缩小’按钮（从9级变为2级），执行缩小地图
的操作。

测试执行时间设置说明：
●每10秒增加5个用户，大概1分30秒之后达到50个用户（3分20秒之后达到100个用
户，6分30秒之后达到200个用户）。

●然后50个用户（或100个用户或200个用户）并发持续执行5分钟。

●然后每10秒减少10个用户，大概到8分钟之后50个用户减少到0（大概11分之后100
个用户减到0，大概18分钟之后200个用户减到0）。

3.3测试项
测试在场景下，事务的完成情况、平均响应时间、服务器的吞吐量、服务器端CPU利用率情况等。

3.4测试结果与分析
3.4.1生成专题产品工作流
3.4.1.1事务通过数与CPU利用率情况
表3.4.1.1
表3.4.1.1是对50个并发用户与100个并发用户，分别在不同的进程数下，完成工作流情况以及对CPU使用情况的汇总。

3.4.1.2用户并发执行5分钟时每秒事务通过数（TPS）
50个并发用户：
由上图可以知道并发执行5分钟时每秒事务通过数，50个用户：
在三个进程时，大概完成127个工作流。

在六个进程时，大概完成213个工作流。

在九个进程时，大概完成281个工作流。

在十二个进程时，大概完成361个工作流。

在十六个进程时，大概完成440个工作流。

100个并发用户：
由上图可以知道并发执行5分钟时每秒事务通过数，50个用户：
在三个进程时，大概完成117个工作流。

在六个进程时，大概完成216个工作流。

在九个进程时，大概完成280个工作流。

在十二个进程时，大概完成348个工作流。

在十六个进程时，大概完成397个工作流。

3.4.1.3用户并发执行5分钟时应用服务器CPU情况50个并发用户：
由上图可以看出System mode CPU Utilization （系统模式下使用 CPU 的时间百分比）随着进程数的增加，平均值基本上控制在10%左右，而User mode CPU Utilization （用户模式下使用 CPU 的时间百分比）随着进程数的增加，平均值最高也就在60%左右，而CPU Utilization （CPU 的使用时间百分比），从最大值来看，十六个进程运行时，CPU 的利用率较高，超过75%，这时需要结合Average load （上一分钟同时处于“就绪”状态的平均进程数）来看正在处理以及等待CPU 处理的队列是否过长。

因为我们的应用服务器是4个CPU ，且都是4核处理器，CPU 的负载=CPU 个数*核数，为了保证性能，理想平均负载是小于CPU 个数*核数*0.7，也就是Average Load 最好小于11.2（也就是在11与12之间），由上图可以看出运行十六个进程，平均负载远远高于理想负载，CPU 的负载压力过高，十二个进程，平均负载在12边缘，最大值超过理想负载。

2.975
6.124
9.445
11.771
15.936
3.227
6.688
9.887
13.156
17.957
2468101214161820三进程六进程九进程十二进程十六进程
Average Load （平均负载）
Average load 平均值Average load 最大值
100个并发用户：
由上图可以看出System mode CPU Utilization（系统模式下使用 CPU 的时间百分比）随着进程数的增加，平均值也是在10%左右，而User mode CPU Utilization（用户模式下使用 CPU 的时间百分比）随着进程数的增加，平均值最高也就在50%左右，而CPU Utilization（CPU 的使用时间百分比），从最大值来看，十六个进程运行时，CPU的利用率也未超过75%。

由上图可以看出在100个用户的情况下，运行十二个进程或十六个进程，平均负载都会超过理想负载。

3.4.2矢量行政区底图显示
3.4.2.1事务响应时间与吞吐量情况
以下是对50、100、200个用户在不同进程情况下，打开矢量行政区页面（Init事务）、放大地图（Zoomout事务）、拖动地图（Move事务）、缩小地图（Zoomin事务）的平均事务响应时间，以及在用户达到最大值时，人工执行操作记录的响应时间即人机交互响应时间，每秒从服务器获取的数据量即每秒吞吐量，CPU使用情况的汇总。

一个进程：
●50个并发用户：
从表3.4.2.1-1中可以看出平均事务响应时间在5秒范围内，从Init事务的人机交互响应时间来看，从页面响应到所有图片显示出来的时间较长，用户体验不好。

●100个并发用户：
表3.4.2.1-2
从表3.4.2.1-2中可以看出平均事务响应时间在5秒范围内，但是Zoomout最大值与平均值相差较大，说明有个别用户等待时间很长，而人机交互响应时间与CPU利用率与50个并发用户时相差不大。

●200个并发用户：
从表3.4.2.1-3中可以看出当并发用户数为200时，Init与Zoomout事务平均响应时间都超过5秒，且有部分用户的响应时间很长，用户体验不好。

三个进程：
●50个并发用户：
从表3.4.2.1-4中可以看出平均事务响应时间在5秒范围内，CPU的利用率也不高，从人机交互响应时间来看，用户体验较好。

●100个并发用户：
从表3.4.2.1-5中可以看出平均事务响应时间在5秒范围内，但是Zoomout最大值与平均值相差较大，说明有个别用户等待时间很长，而人机交互响应时间与CPU利用率与50个并发用户时相差不大。

●200个并发用户：
表3.4.2.1-6
从表3.4.2.1-6中可以看出当并发用户数为200时，Init与Zoomout事务平均响应时间都超过5
秒。

从人机交互时间看，用户体验不好。

五个进程：
●50个并发用户：
表3.4.2.1-7
从表3.4.2.1-7中可以看出Init事务的平均响应时间超过5秒，Zoomout、Move、Zoomin事务的响应时间较短，且与人机交互响应时间相差不大，可见系统反应很快，用户体验很好。

●100个并发用户：
表3.4.2.1-8
从表3.4.2.1-8中可以事务的平均响应时间都在5秒以内，且人机交互响应时间很短，用户体验很好。

●200个并发用户：
从表3.4.2.1-9中可以看出当并发用户数为200时，Init事务的平均响应时间超过5秒，人机交互响应时间也较长，用户体验不好。

3.4.2.2用户每秒点击数与吞吐量情况 50个并发用户：
一个进程的每秒点击数与吞吐量：
图3.4.2.2-1 三个进程的每秒点击数与吞吐量：
图3.4.2.2-2 五个进程的每秒点击数与吞吐量：
图3.4.2.2-3
点击数的趋势基本保持一致，且曲线平稳，说明服务器运行稳定，而五个进程出现吞吐量与每秒点击数大幅度下降，说明服务器响应时间变慢，在（48秒与3分44秒时），有其他事件影响了服务器的处理能力。

100个并发用户：
一个进程的每秒点击数与吞吐量：
图3.4.2.2-4
三个进程的每秒点击数与吞吐量：
图3.4.2.2-5
五个进程的每秒点击数与吞吐量：
图3.4.2.2-6
量与每秒点击数的趋势基本一致，当用户增加的时候较为波动，当用户达到最大并发数后，曲线较为平稳，说明服务器运行稳定，而在用户并发执行期间（大概3分30秒~8分30秒），五个进程的吞吐量最大，其次是三个进程，最后是一个进程，吞吐量越大说明服务器处理能力越好。

200个并发用户：
一个进程的每秒点击数与吞吐量：
图3.4.2.2-7
三个进程的每秒点击数与吞吐量：
图3.4.2.2-8
五个进程的每秒点击数与吞吐量：
图3.4.2.2-9
而200人并发时，应该在6分30秒的时候就达到并发用户最大值，而不管是在一个进程、三个进程还是五进程，在7分30秒左右，都出现吞吐量与每秒点击数大幅度下降，说明随着用户数不断增加，服务器响应时间变的很慢，且在并发执行的5分钟内，一个进程与三个进程的吞吐量比并发执行前低很多，而五个进程的吞吐量趋势也不平稳。

3.4.2.3应用服务器平均负载情况
50个并发用户：
图3.4.2.3-1
由图3.4.2.3-1显示，在一个进程、三个进程、五个进程时，平均负载都在理想范围内，而最大值也在理想负载范围边缘，所以服务器应该可以支持50个用户并发执行，五个进程的负载最好。

●100个并发用户：
图3.4.2.3-2
由图3.4.2.3-2显示，在一个进程和三个进程时，平均负载还在理想范围内，最大值也在理想负载范围边缘，而五个进程的负载就太高了，所以当并发运行100人时，开五个进程会使服务器负载过高。

●200个并发用户：
图3.4.2.3-3
由图3.4.2.3-3显示，在一个进程和三个进程时，平均负载还在理想范围内，但是最大值都比理想负载高很多，说明并发运行200人会对服务器造成较大压力。

3.4.3影像底图显示
3.4.3.1事务响应时间与吞吐量情况
以下是对50、100、200个用户在不同进程情况下，打开影像底图页面（Init事务）、放大地图（Zoomout事务）、拖动地图（Move事务）、缩小地图（Zoomin事务）的平均事务响应时间，以及在用户达到最大值时，人工执行操作记录的响应时间即人机交互响应时间，每秒从服务器获取的数据量即每秒吞吐量，CPU使用情况的汇总。

一个进程：
50个并发用户：
从表3.4.3.1-1中可以看出平均事务响应时间除了Zoomin事务外都5秒范围，且人机交互响应时间来看，从页面响应到所有图片显示出来的时间较长，而从CPU的利用率来看，说明服务器不是很繁忙，但是响应时间却很长，吞吐量较高，说明影响底图显示对带宽依赖较大。

●100个并发用户：
从表3.4.3.1-2中可以看出平均事务响应时间远远超过5秒，而且人机交互响应时间也很长，所有页面显示出来需要较长时间。

●200个并发用户：
从表3.4.3.1-3中可以看出当并发用户数为200时，页面响应时间很长。

三个进程：
●50个并发用户：
从表3.4.3.1-4中可以看出Init事务的平均响应时间在5秒以上，CPU的利用率不高，吞吐量较大，从人机交互响应时间来看，用户体验一般。

●100个并发用户：
从表3.4.3.1-5中可以看出只有Zoomin事务的平均响应时间在5秒范围内，用户体验一般。

●200个并发用户：
从表3.4.3.1-6中可以看出当并发用户数为200时，事务平均响应时间远远超过5秒。

从人机交互时间看，用户体验不好。

五个进程：
●50个并发用户：
从表3.4.3.1-7中可以看出Init事务的平均响应时间超过5秒，Zoomout、Move、Zoomin事务的响应时间在5秒之内。

●100个并发用户：
从表3.4.3.1-8中可以看出只有Zoomin事务的平均响应时间在5秒以内，人机交互响应时间较长，用户体验不好。

●200个并发用户：
从表3.4.2.1-9中可以看出当并发用户数为200时，事务的平均响应时间远远超过5秒，人机交互响应时间也较长，用户体验不好。

3.4.3.2应用服务器平均负载情况
●50个并发用户：
图3.4.3.2-1
由图3.4.3.2-1显示，在一个进程、三个进程、五个进程的情况下，平均负载都在理想范围内，而一个进程与三个进程的最大值也在理想负载范围内，五个进程的最大值比理想负载高。

●100个并发用户：
图3.4.3.2-2
由图3.4.3.2-2显示，在一个进程、三个进程、五个进程的情况下，平均负载都在理想范围内，最大值也在理想负载范围内。

200个并发用户：
图3.4.3.2-3
由图3.4.3.2-3显示，在一个进程、三个进程、五个进程的情况下，平均负载都在理想范围内，而最大值也在理想负载内。

3.4.4前台标绘站点
3.4.4.1前台标绘2000个站点
3.4.4.1.1事务响应时间与吞吐量情况
以下是对50、100、200个用户在不同进程情况下，打开前台标绘2000个站点页面（Init事务）、放大地图（Zoomout事务）、拖动地图（Move事务）、缩小地图（Zoomin事务）的平均事务响应时间，以及在用户达到最大值时，人工执行操作记录的响应时间即人机交互响应时间，每秒从服务器获取的数据量即每秒吞吐量，CPU使用情况的汇总。

一个进程：
●50个并发用户：
表3.4.4.1.1-1
从表3.4.4.1.1-1中可以看出平均事务响应时间都在5秒范围内，人机交互响应时间较短，用户体验不错，CPU利用率不高。

●100个并发用户
从表3.4.4.1.1-2中可以看出平均事务响应时间都在5秒范围内，人机交互响应时间来看，打开前台标绘页面的时间较长。

●200个并发用户
从表3.4.4.1.1-3中可以看出当并发用户数为200时，Init事务的平均响应时间远远超过5秒，打开页面速度较慢。

三个进程：
●50个并发用户
从表3.4.4.1.1-4中可以看出事务的平均响应时间都在5秒以内，人机交互时间较短，用户体验较好，CPU利用率不高。

●100个并发用户
从表3.4.4.1.1-5中可以看出事务的平均响应时间都在5秒以内，与并发50个用户平均时间相差不大。

●200个并发用户
从表3.4.4.1.1-6中可以看出当并发用户数为200时，Init与Zoomout事务平均响应时间超过5秒。

五个进程：
●50个并发用户：
从表3.4.4.1.1-7中可以看出事务的平均响应时间都在5秒以内，用户体验很好，CPU利用率不高。

●100个并发用户
从表3.4.4.1.1-8中可以看出事务的平均响应时间都在5秒以内，用户体验不错。

●200个并发用户
从表3.4.4.1.1-9中可以看出当并发用户数为200时，Init事务的平均响应时间远远超过5秒，打开前台标绘站点页面需要较长时间。

3.4.4.1.2应用服务器平均负载情况
●50个并发用户：
图3.4.4.1.2-1
由图3.4.4.1.2-1显示，在一个进程、三个进程、五个进程的情况下，平均负载都在理想范围内，而五个进程的最大值比理想负载高。

●100个并发用户：
图3.4.4.1.2-2
由图3.4.4.1.2-2显示，在一个进程、三个进程的情况下，平均负载都在理想范围内，最大值也
在理想负载范围内，运行五个进程，平均负载超过理想范围。

●200个并发用户：
图3.4.4.1.2-3
由图3.4.4.1.2-3显示，在一个进程、三个进程的情况下，平均负载都在理想范围内，而一个进程的最大值超过理想负载，五个进程的平均负载与最大负载远远超过理想负载。

3.4.4.2前台标绘3000个站点
3.4.4.2.1事务响应时间与吞吐量情况
以下是对50、100、200个用户在不同进程情况下，打开前台标绘3000个站点页面（Init事务）、放大地图（Zoomout事务）、拖动地图（Move事务）、缩小地图（Zoomin事务）的平均事务响应时间，以及在用户达到最大值时，人工执行操作记录的响应时间即人机交互响应时间，每秒从服务器获取的数据量即每秒吞吐量，CPU使用情况的汇总。

一个进程：
●50个并发用户：
从表3.4.4.2.1-1中可以看出平均事务响应时间都在5秒范围内，用户体验不错，CPU利用率不高。

●100个并发用户
从表3.4.4.2.1-2中可以看出平均事务响应时间都在5秒范围，打开页面花费较长时间。

●200个并发用户
从表3.4.4.2.1-3中可以看出当并发用户数为200时，Init与Zoomout事务的平均响应时间超过5秒。

三个进程：
●50个并发用户
从表3.4.4.2.1-4中可以看出事务的平均响应时间在3秒以内，人机交互时间较短，用户体验较好，CPU利用率低。

●100个并发用户
表3.4.4.2.1-5
从表3.4.4.2.1-5中可以看出事务的平均响应时间都在5秒以内，CPU利用率不高。

●200个并发用户
从表3.4.4.2.1-6中可以看出当并发用户数为200时，Init与Zoomout事务平均响应时间超过5秒。

五个进程：
●50个并发用户：
从表3.4.4.2.1-7中可以看出事务的平均响应时间都在3秒以内，用户体验很好。

●100个并发用户
表3.4.4.2.1-8
从表3.4.4.2.1-8中可以看出事务的平均响应时间都在5秒以内，用户体验较好。

●200个并发用户
从表3.4.4.2.1-9中可以看出当并发用户数为200时，Init事务的平均响应时间远远超过5秒，打开前台标绘站点页面需要较长时间。

3.4.4.2.2应用服务器平均负载情况
●50个并发用户：
图3.4.4.2.2-1
由图3.4.4.2.2-1显示，在一个进程和三个进程的情况下，平均负载都在理想范围内，而五个进程的平均负载比理想负载高。

●100个并发用户：
图3.4.4.2.2-2
由图3.4.4.2.2-2显示，在一个进程、三个进程、五个进程的情况下，平均负载都在理想范围内，而最大值都超过理想负载范围内。

200个并发用户：
图3.4.4.2.2-3
由图3.4.4.2.2-3显示，在一个进程、三个进程的情况下，平均负载都在理想范围内，而最大值都超过理想负载。

3.4.4.3前台标绘5000个站点
3.4.4.3.1事务响应时间与吞吐量情况
以下是对50、100、200个用户在不同进程情况下，打开前台标绘5000个站点页面（Init事务）、放大地图（Zoomout事务）、拖动地图（Move事务）、缩小地图（Zoomin事务）的平均事务响应时间，以及在用户达到最大值时，人工执行操作记录的响应时间即人机交互响应时间，每秒从服务器获取的数据量即每秒吞吐量，CPU使用情况的汇总。

一个进程：
●50个并发用户：
从表3.4.4.3.1-1中可以看出平均事务响应时间都在5秒范围内，CPU利用率低。

●100个并发用户
表3.4.4.3.1-2
从表3.4.4.3.1-2中可以看出平均事务响应时间都在5秒范围，CPU利用率不高。

●200个并发用户
从表3.4.4.3.1-3中可以看出当并发用户数为200时，Init与Zoomout事务的平均响应时间超过5秒，打开页面需要较长时间。

三个进程：
●50个并发用户
从表3.4.4.3.1-4中可以看出事务的平均响应时间在5秒以内，人机交互时间较短，用户体验较好。

●100个并发用户
从表3.4.4.3.1-5中可以看出init事务的平均响应时间超过5秒，打开页面需要较长时间。

●200个并发用户
从表3.4.4.3.1-6中可以看出当并发用户数为200时，Init与Zoomout事务平均响应时间超过5秒，大部分用户打开页面都需要较长时间。

五个进程：
●50个并发用户：
从表3.4.4.3.1-7中可以看出事务的平均响应时间都在5秒范围内，用户体验较好。

●100个并发用户
从表3.4.4.3.1-8中可以看出事务的平均响应时间都在5秒范围内。

●200个并发用户
表3.4.4.3.1-9
从表3.4.4.3.1-9中可以看出当并发用户数为200时，Init事务的平均响应时间远远超过5秒，打开前台标绘站点页面需要较长时间。

3.4.4.3.2应用服务器平均负载情况
●50个并发用户：
图3.4.4.3.2-1
由图3.4.4.3.2-1显示，在一个进程和三个进程的情况下，平均负载都在理想范围内，而五个进程的平均负载比理想负载高。

●100个并发用户：
图3.4.4.3.2-2
由图3.4.4.3.2-2显示，在一个进程、三个进程的情况下，平均负载都在理想范围内，而五个进程超过理想负载范围内。

●200个并发用户：
图3.4.4.1.2-3
由图3.4.4.1.2-3显示，在一个进程、三个进程的情况下，平均负载都在理想范围内，而一个进程最大值超过理想负载。

3.4.5后台生成站点
3.4.5.1后台生成2000个站点
3.4.5.1.1事务响应时间与吞吐量情况
以下是对50、100、200个用户在不同进程情况下，打开后台生成2000个站点页面（Init事务）、放大地图（Zoomout事务）、拖动地图（Move事务）、缩小地图（Zoomin事务）的平均事务响应时间，以及在用户达到最大值时，人工执行操作记录的响应时间即人机交互响应时间，每秒从服务器获取的数据量即每秒吞吐量，CPU使用情况的汇总。

一个进程：
50个并发用户：。