LoadRunner压力测试结果分析探讨
LoadRunner性能测试报告讲解
xxx系统性能测试报告姓名：班级：学号：目录1 前言 (3)2 被测系统定义 (3)2.1 功能简介 (3)2.2 性能测试指标 (3)3 系统结构及流程 (4)3.1 系统总体结构 (4)3.2 功能模块 (4)3.3 业务流程 (5)3.4 关键点描述 (5)3.5 性能测试环境 (5)4 性能测试 (6)4.1 性能测试概述 (6)4.2 测试目的 (6)4.3 测试方法及测试用例 (6)4.4 测试指标及期望 (7)4.5 测试数据准备 (8)4.6 运行状况记录 (9)5 测试过程及结果描述 (9)5.1 测试描述 (9)5.2 测试场景 (10)5.3 测试结果 (10)6测试分析和结论 (14)1前言目前，随着Web Tours订票系统在生产状态下日趋稳定、成熟，系统的性能问题也逐步成为了我们关注的焦点：随着订票过程中大数据量的“冲击”，在客户信息信息进入时，系统能稳定在什么样的性能水平，面临公司业务冲刺时，系统能否经受住“考验”，这些问题需要通过一个完整的性能测试来给出答案。
本报告前部分即是基于上述考虑，参考科学的性能测试方法而撰写的，用以指导即将进行的Web Tours订票系统的性能测试。
2HP Web Tours系统定义HP Web Tours 订票系统作为本次测试的被测系统，该业务系统的主要功能包括：搜索航班，预订机票并查看航班路线。
在本次测试中，将针对上述的功能进行压力测试，检查并评估在模拟环境中，系统对负载的承受能力，在不同的用户连接情况下，系统地吞吐能力和响应能力，以及在预计的数据容量中，系统能够容忍的最大用户数。
2.1功能简介HP Web Tours主要功能如下：➢用户注册➢登录➢查询航班2.2性能测试指标本次测试是针对HP Web Tours订票系统的性能特征和系统的性能调优而进行的，主要需要获得如下的测试指标。
1、系统的响应能力：即在各种负载压力情况下，系统的响应时间，也就是从客户端交易发起，到服务器端交易应答返回所需要的时间，包括网络传输时间和服务器处理时间。
loadrunner测试报告
loadrunner测试报告标题：《深入了解LoadRunner测试报告》引言：在软件开发和测试过程中，性能测试是非常重要的一环。
而作为广泛应用的性能测试工具之一，LoadRunner提供了详细的测试报告，可以帮助开发人员和测试人员进行性能问题的分析和解决。
本文将深入探讨LoadRunner测试报告的内容和意义，以及如何正确解读和分析测试报告。
一、LoadRunner测试报告的概述LoadRunner测试报告是基于所执行的性能测试结果生成的一份详尽报告。
它包含了多个重要的信息和数据，用于评估系统在负载下的性能表现。
LoadRunner测试报告一般由多个部分组成，包括概要信息、实际负载情况、响应时间分析、错误率统计、并发用户数、资源占用情况等。
二、测试报告的概要信息LoadRunner测试报告的概要信息部分提供了对整个测试过程的总体概述。
这一部分包括测试的目的和背景、测试场景和测试数据的设置、测试运行时间、测试结果的关键指标等。
通过概要信息，我们可以了解测试的整体情况，为后续的分析提供背景和依据。
三、实际负载情况的分析实际负载情况是LoadRunner测试报告中一个非常重要的部分。
通过分析实际负载情况，我们可以了解系统在不同负载下的性能表现。
在这一部分中，我们将关注并发用户数、事务响应时间、吞吐量等。
通过对负载情况的分析，我们可以确定系统在预期负载下的性能状况，并找出可能存在的性能瓶颈。
四、响应时间分析响应时间是系统性能的一个重要指标，也是用户体验的直接体现。
在LoadRunner测试报告中，响应时间分析提供了针对每个事务的详细响应时间数据。
我们可以通过对响应时间的分析，找出系统中响应时间过长的事务，并进行优化。
此外，还可以通过比较不同负载下的响应时间数据，进一步了解系统对负载变化的适应能力。
五、错误率统计错误率统计是测试报告中的又一重要部分。
通过统计测试过程中出现的错误次数和错误率，我们可以快速定位系统中存在的问题。
LoadRunner常见测试结果分析（转）
LoadRunner常见测试结果分析（转）
在测试过程中，可能会出现以下常见的几种测试情况：
一、当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降这种情形表明：
* 从事务响应时间曲线图持续上升表明系统的处理能力在下降，事务的响应时间变长；
* 持续平衡表明并发用户数达到一定数量，在多也可能接受不了，再有请求数，就等待；
* 当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。
如果系统没有这种下降机制，响应时间越来越长，直到系统瘫痪。
从以上的结果分析可发现是由以下的原因引起：
1. 程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2. 内存泄露；
二、CPU的使用率不断上升，内存的使用率也是不断上升，其他一切都很正常；
表明系统中可能产生资源争用情况；
引起原因：
开发人员注意资源调配问题。
三、所有的事务响应时间、cpu等都很正常，业务出现失败情况；
引起原因：
数据库可能被锁，就是说，你在操作一张表或一条记录，别人就不能使用，即数据存在互斥性；
当数据量大时，就会出现数据错乱情况。
(情绪管理)LR压力测试结果分析探讨最全版
（情绪管理）LR压力测试结果分析探讨LoadRunner压力测试结果分析探讨分析原则：1.具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）2.查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈网络瓶颈（对局域网，能够不考虑）服务器操作系统瓶颈（参数配置）中间件瓶颈（参数配置，数据库，web服务器等）应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）分析的信息来源：1.根据场景运行过程中的错误提示信息2.根据测试结果收集到的监控指标数据壹．错误提示分析分析实例：1．Error:Failedtoconnecttoserver“172.17.7.230″:[10060]Connection Error:timedoutError:Server“172.17.7.230″hasshutdowntheconnectionpre maturely分析：A、应用服务死掉。
（小用户时：程序上的问题。
程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）B、应用服务没有死（应用服务参数设置问题）对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connectionrefused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！C、数据库的连接(数据库启动的最大连接数（跟硬件的内存有关）)D、我们的应用程序spring控制的最大链接数太低2.Error:Pagedownloadtimeout(120seconds)hasexpired分析：A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大多D、实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境3.Error“http://172.17.7.230/Home.do....”分析：A、脚本设计错误，造成页面异常。
loadrunner结果分析
loadrunner结果分析LoadRunner结果分析文章分类:综合技术LoadRunner结果分析器(以下简称Analysis或Analysis模块)是一个独立的模块，它可以将测试结果和监控数据转化为数据库数据，以利于分析处理。
测试人员可以在分析器中选择感兴趣的图标，通过合并图，交叉图和自动关联等手段，对测试结果和监控数据进行分析处理，以确定性能瓶颈及其产生原因。
最后，分析器可以根据测试人员选择的感兴趣部分，自动生成HTML格式或Word格式的性能报告，这些报告可以作为福建，和性能测试报告一起提交，提供性能参考。
LoadRunner Controller在测试结束后，可以自动从压力产生器上将测试结果收集起来，并且和监控数据一起，生成结果数据，保存在设置的运行结果目录中。
分析器启动时，如果压力产生器在远端机器上，又没有选择自动收集数据，则会先收集测试结果数据。
否则会打开运行结果文件，将结果文件经过处理后导入到Microsoft Access数据库，然后按照设置的模板自动打开某些结果分析图。
——————————————现对各种图做一个简要总结————————————1、分析概要2、 Vuser图: 主要包括正在运行的Vuser图、 Vuser概要图、集合图。
此图可用于确定任何给定环境中服务器上的Vuser负载。
默认情况下，此图仅显示状态为运行的Vuser。
要查看其他的Vuser状态，请将筛选条件设置为所需的状态(^_^ ^_^ 我至今还没有找到设置筛选条件的地方)。
3、事务图:运行场景或会话步骤之后，可以使用一个或多个事务图分析测试过程中执行的事务。
事务图主要包括:平均事务响应时间图、每秒事务数图、每秒事务总数 ... ...3.1、平均事务响应时间图: 对于每个方式，此图将以不同的方式显示。
关于粒度的选择，差资料 ... ...注意: 默认情况下，只显示已通过的事务。
你可以将平均事务响应时间图与正在运行的Vuser图进行比较，了解正在运行的Vuser的数目对事务性能时间产生的影响。
LoadRunner 测试结果分析
Transactions（用户事务分析）用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary（事务综述）对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
3、Transactions per Second（每秒通过事务数/TPS）“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。
通过它可以确定系统在任何给定时刻的时间事务负载。
分析TPS主要是看曲线的性能走向。
将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
4、Total Transactions per Second（每秒通过事务总数）“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
5、Transaction Performance Sunmmary（事务性能摘要）“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。
LoadRunner测试结果分析
LoadRunner测试结果分析一、LoadRunner测试结果分析之我见LoadRunner生成测试结果并不代表着这次测试结果的结束，相反，这次测试结果的重头戏才刚刚开始。
如何对测试结果进行分析，关系着这次测试的成功与否。
网上关于LoadRunner测试结果如何分析的介绍相当匮乏，在总结他人的观点和自己的实验体会基础上来介绍如何进行LoadRunner测试结果分析。
1. LoadRunner测试结果分析的第一步应该是查看分析综述（Analysis Summary），其包括统计综述（Statistics Summary）、事务综述（Transaction Summary）、HTTP 响应综述（HTTP Responses Summary）三部分。
在统计综述中查看Total Errors的数量，HTTP 响应综述中查看HTTP 404数量，若数值相对较大（HTTP 404则相对于HTTP 200），则说明系统测试中出错较多，系统系能有问题；另外查看事务的平均响应时间和其90%的事务平均响应时间，若时间过长，超过测试计划中的要求值，则说明系统的性能不满足我们的要求。
2. 第二步对LoadRunner测试结果图进行分析，首先对事务综述（Transaction Summary）进行分析，该图可以直观地看出在测试时间内事务的成功与失败情况，所以比第一步更容易判断出被测系统运行是否正常。
3. 接着分析事务平均响应时间（Average Transaciton Response Time），若事务平均响应时间曲线趋高，则说明被测系统处理事务的速度开始逐渐变慢，即被测系统随着运行时间的变化，整体性能不断下降。
当系统性能存在问题时，该曲线的走向一般表现为开始缓慢上升，然后趋于平稳，最后缓慢下降。
原因是：被测系统处理事务能力下降，事务平均响应时间变长，在曲线上表现为缓慢上升；而并发事务达到一定数量时，被测系统无法处理多余的事务，此时曲线变现为趋于平稳；当一段时间后，事务不断被处理，其数量减少，在曲线上表现为下降。
LoadRunner性能测试结果分析
LoadRunner性能测试结果分析性能测试的需求指标：本次测试的要求是验证在30分钟内完成2000次⽤户登录系统，然后进⾏考勤业务，最后退出，在业务操作过程中页⾯的响应时间不超过3秒，并且服务器的CPU使⽤率、内存使⽤率分别不超过75%、70%LoadRunner性能测试结果分析内容：1、结果摘要LoadRunner进⾏场景测试结果收集后，⾸先显⽰的该结果的⼀个摘要信息，如图1- 2所⽰。
概要中列出了场景执⾏情况、“Statistics Summary（统计信息摘要）”、“Transaction Summary（事务摘要）”以及“HTTP Responses Summary（HTTP响应摘要）”等。
以简要的信息列出本次测试结果。
图1- 2性能测试结果摘要图场景执⾏情况：该部分给出了本次测试场景的名称、结果存放路径及场景的持续时间，如图1- 3所⽰。
从该图我们知道，本次测试从15:58:40开始，到16:29:42结束，共历时31分2秒。
与我们场景执⾏计划中设计的时间基本吻合。
图1- 3场景执⾏情况描述图Statistics Summary（统计信息摘要）该部分给出了场景执⾏结束后并发数、总吞吐量、平均每秒吞吐量、总请求数、平均每秒请求数的统计值，如图1- 4所⽰。
从该图我们得知，本次测试运⾏的最⼤并发数为7，总吞吐量为842,037,409字节，平均每秒的吞吐量为451,979字节，总的请求数为211,974，平均每秒的请求为113.781，对于吞吐量，单位时间内吞吐量越⼤，说明服务器的处理能越好，⽽请求数仅表⽰客户端向服务器发出的请求数，与吞吐量⼀般是成正⽐关系。
图1- 4统计信息摘要图Transaction Summary（事务摘要）该部分给出了场景执⾏结束后相关Action的平均响应时间、通过率等情况，如图1- 5所⽰。
从该图我们得到每个Action的平均响应时间与业务成功率。
注意：因为在场景的“Run-time Settings”的“Miscellaneous”选项中将每⼀个Action当成了⼀个事务执⾏，故这⾥的事务其实就是脚本中的Action。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
LoadRunner 压力测试结果分析探讨分析原则:1.具体问题具体分析（这是由于不同的应用系统，不同的 测试目的，不同 的性能关注点）2. 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈 网络瓶颈（对局域网，可以不考虑）服务器操作系统瓶颈（参数配置）中间件瓶颈（参数配置，数据库,web 服务器等）瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）分析的信息来源:1.根据场景运行过程中的错误提示信息2.根据测试结果收集到的监控指标数据 .错误提示分析 分析实例:1. Error: Failed to connect to server Connection分析:A 应用服务死掉。
（小用户时：程序上的问题。
程序上处理数据库的问题，实际测试中多半是 服务器链接的配置问题）B 、应用服务没有死（应用服务参数设置问题）应用“172.17.7.230 〃 ： [10060]Error: timed out Error: Server conn ecti on p rematurely“172.17.7.230 〃 has shut down the对应的Apache 和tomcat 的最大链接数需要修改，如果连接时收到 connection refused 消息，说明应提高相应的服务器最大连接的设置，增加幅 度要根据实际情况和服务器硬件的情况来定，建议每次增加 25%!C 数据库的连接（数据库启动的最大连接数（跟硬件的内存有关） ） D 我们的应用程序spring 控制的最大链接数太低2. Error: Page download timeout (120 seconds) has expired分析：实际测试时有些资源需要请求外网，而我们的测试环境是局域网环境3. Error “http://172.17.7.230/Home.do 分析：A 脚本设计错误，造成页面异常。
服务器有响应!B 、并发数过大，造成服务器响应延迟。
4. Error page “text=xxxxx ” 分析：A 脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问 异常。
B 、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。
只能反复修改脚本!．监控指标数据分析 1．Vusers 数A 、应用服务参数设置太大导致服务器的瓶颈 B 、页面中图片太多 C 、在程序处理表的时候检查字段太大多 D 、Loadrunner 系统设置的虚拟用户数目。
Vuser 去实际调用事先制作的脚本文件中的应用。
每个 Vuser 产生响应的操作，所有的操作对服务器形成并发。
颜色比例度量图最小值图平均值图最大值图中间值图 SD1 Run 0.0 21.25 44 41 21.276在实际测试中， Vusers 可以根据实际情况的需要，在测试过程中增加或者减少。
2．最大并发用户数：颜色比例度量最小值平均值最大值 SD100 Apache CPU使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.0430.01 已发送 KB/ 秒(Apache):172.17.7.210 6 1430.371 2689.333 327.9240.1 点击次数 / 秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201应用系统在当前环境下能承受的最大并发用户数。
在方案运行中，如果出现了大批用户的业务操作失败，或出现了服务器 shutdown 的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
从上图可以看出：在测试运行到 4个小时左右的时候， apache 的点击数 /秒开始迅速增加！3．业务操作响应时间：使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
颜色比例度量1 最小值1 平均值1 最大值分析事务的响应情况，要每次详细分析，目前还只能观察到响应时间过长的事务！4．每秒点击数负载测试期间每秒内Vuser 在Web 服务器上点击的次数。
可根据点击次数来估算Vuser 生成的负载数。
颜色比例度量图最小值平均值图最大值图中间值图SD1 点击次数69.908 105.736 130.244 103.666 12.186从图中不难看出，在4 小时的时候，点技数明显增高。
和apache 的每秒点击数增大的时间相吻合！5．吞吐量负载测试期间Web 服务器上的吞吐量（字节）。
吞吐量表示在任何指定秒内Vuser 从服务器接收到的数据量。
此图可估计Vuser 生成的负载量（服务器吞吐量）。
颜色比例度量图最小值平均值图最大值图中间值图SD1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473同样，从图中可以看出，在4 个小时的时候，web 服务器的吞吐量开始增高。
在图中还可以看到吞吐量的走势图，从开始到进行到4 个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。
6．下载组件大小每个页面的组件大小，且包括组件的标头的大小！页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner 的报告分析工具来分析。
页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！7．Apache 资源显示APACHE web 服务器上的资源摘要。
前面已经提到过以并发点击数为主。
颜色比例度量最小值平均值最大值SD100 Apache CPU 使用情况 (Apache):172.17.7.210 0.777 0.852 0.93 0.0430.01 已发送 KB/ 秒(Apache):172.17.7.210 6 1430.371 2689.333 327.9240.1 点击次数 /秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201三．服务器资源监控指标：目前通过 top 监察）内存：Linux 资源监控中指标内存页交换速率（ Paging rate ），如果该值偶尔走高，表明当时有线程竞争内 存。
如果持续很高，则内存可能是瓶颈。
也可能是内存访问命中率低。
内存资源成为系统性能的瓶颈的征兆很高的换页率 (high pageout rate);进程进入不活动状态 ;交换区所有磁盘的活动次数可高可高的全局系统 CPU 利用率 ;内存不够出错 (out of memory errors)处理器：说明，目前系统用应用的 cpu 也是测试的瓶颈！CPU 资源成为系统性能的瓶颈的征兆很慢的响应时间 (slow response time)CPU 空闲时间为零 (zero percent idle CPU)过高的用户占用 CPU 时间 (high percent user CPU)实际测试中，当并发点击数出现突然剧增前后， 中内存存在瓶颈！内存的 PR 值则居高 25 不下。
说明目前测试的系统Linux 资源监控中指标 CPU 占用率持续超过 同，有资料表明 95 ％），表明瓶颈是 CPU 。
80%（对该值的要求， 根据具体应用和机器配置而要求不实际测试中， 当并发点技数出现突然增加前后， cpu 的占用率持续保持在 8 6 ％以上！过高的系统占用 CPU 时间(high percent system CPU)长时间的有很长的运行进程队歹y (large run queue size sustained over time)四.数据库服务器:数据库服务器目前测试观察，当 web 服务器点击率增大时，观察 mysql 数据库的最大连接数，仍未超过系统设置的最大连接数。
所以，暂时未发现数据库的瓶颈！五.结论以上报告分析中的数据、图标均来自同一次测试。
是在平时测试中挑出的一次现象比较明显，比较利 于观察的作为分析案例。
根据以上综合分析，当前测试环境下，当应用系统产生最大 533.667的并发压力。
平均负载压力 114.352。
根据分析，用户在 4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。
同时，测试服务器的硬件配置和实际服务器的配置还有一定的差 距！转一份在51testing 上的讨论一一如何测试一个门户网站是否可以支持 10万用户同时在线?Jackei 阅读（6074） 评论⑸ 编辑 收藏 网摘 所属分这个帖子的内容比较典型，大家有兴趣可以也思考一下。
先是楼主提出问题:亠最近公司一个项目，是个门户网站，需要做性能测试，根据项目特点定出了主要测试项和测 试方案 =一种是测试几个常用页面能接受的最大并发数（用户名参数化，设置集合点策略）二一种是测试服务器长时间压力下，用户能否正常操作（用户名参数化，迭代运行脚本） 还有一种则需要测试服务器能否接受10万用户同时在线操作，但使用的Loadrunner的Iicense 只能支持1万用户，请问这时该如何制定该方案？后面跟着大家的回复:找10台电脑也没用，license 仍然只支持10000个。
找HP 支持。
当然，前提是你有足够的钱。
测到10000用户并发。
我认为，通常情况下 10000用户并发，支持100000 用户在线，没有问题的。
Posted on 2006-11-16 01:21网友 xingcyx 的回复: =1、 2、网友jackloo 的回复:二总的来说这一类的性能指标对大多数软件来说没什么实际意义，更多的是对硬件的要求。
—如果是用IIS 做应用服务器的话，单台可承受的最大并发数不可能达到 10万级，那就必须要使用集群，通过多台机器做负载均衡来实现；_如果是用websphere 之类的应用服务器的话，单台可承受的最大并发数可以达到 级，但为性能考虑还是必须要使用集群，通过多台机器做负载均衡来实现； 一那么，你只要集群的服务器足够多，10万并发数当然可以达到了。
通常有1个简单的计算方式，1个连接产生1个session ，每个session 在服务器上有个 内存空间大小的设置，在 NT 上是3M ，那么10万并发就需要300G 内存，当然实际使用 中考虑其他程序也占用内存，所以准备的内存数量要求比这个还要多一些。
还有10万个用户同时在线，跟 10万个并发数是完全不同的 2个概念。
这个楼上已经说 了。
但如何做这个转换将 10万个同时在线用户转换成多少个并发数呢？ 一这就必须要有大量的历史日志信息来支撑了。
系统日志需要有同时在线用户数量的日志信 息，还需要有用户操作次数的日志信息，这 2个数据的比例就是你同时在线用户转换到并发数的比例。