21 测试环境
作者使用了Tomcat作为Web服务器进行测试，被测试的内容是一个jsp文件和一个servlet，jsp文件调用JavaBean、打印相关信息，servlet接受用户参数、调用javabean、输出相关信息。详细的内容请参考作者提供的JMeterwar的内容。
22 安装启动JMeter
大家可以到通过>
现在，请使用%JMeter%/bin下面的jmeterbat批处理文件来启动JMeter的可视化界面，下面的工作都将在这个可视化界面界面上进行 *** 作。下面的是JMeter的可视化界面的屏幕截图。
图一： JMeter打开时的屏幕截图
图一： JMeter打开时的屏幕截图
23 建立测试计划（Test Plan）
测试计划描述了执行测试过程中JMeter的执行过程和步骤，一个完整的测试计划包括一个或者多个线程组(Thread Groups)、逻辑控制（Logic Controller）、实例产生控制器（Sample Generating Controllers）、侦听器(Listener)、定时器（Timer）、比较（Assertions）、配置元素（Config Elements）。打开JMeter时，它已经建立一个默认的测试计划,一个JMeter应用的实例只能建立或者打开一个测试计划。
现在我们开始填充一个测试计划的内容，这个测试计划向一个jsp文件和一个servlet发出请求，我们需要JMeter模拟五个请求者（也就是五个线程），每个请求者连续请求两次，下面的章节介绍了详细的 *** 作步骤。
24 增加负载信息设置
这一步，我们将向测试计划中增加相关负载设置,是Jmeter知道我们需要模拟五个请求者，每个请求者在测试过程中连续请求两次。详细步骤如下：
1 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'Thread Group，界面右边将会出现他的设置信息框。
2 Thread Group有三个和负载信息相关的参数：
Number of Threads： 设置发送请求的用户数目
Ramp-up period： 每个请求发生的总时间间隔，单位是秒。比如你的请求数目是5，而这个参数是10，那么每个请求之间的间隔就是10／5，也就是2秒
Loop Count： 请求发生的重复次数，如果选择后面的forever（默认），那么 请求将一直继续，如果不选择forever，而在输入框中输入数字，那么请求将重复 指定的次数，如果输入0，那么请求将执行一次。
根据我们演示例子的设计，我们应该将Number of Threads设置为5，Ramp-up period设置为0（也就是同时并发请求），不选中forever，在Loop Count后面的输入框中输入2，设置后的屏幕截图如下：
图二：设置好参数的Thread Group。
图二：设置好参数的Thread Group。
25 增加默认>
实际的测试工作往往是针对同一个服务器上Web应用展开的,所以Jmeter提供了这样一种设置, 在默认>
我们这里将采用这种属性。你可以通过下面的步骤来设置默认>
1 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'config element'>
2 默认>
protocal：发送测试请求时使用的协议
server name or ip：被测试服务器的ip地址或者名字
path： 默认的起始位置。比如将path设置为／jmeter，那么所有的>
port number： 服务器提供服务的端口号
我们的测试计划将针对本机的Web服务器上的Web应用进行测试，所以protocal应该是>
图三： 测试计划中使用的默认>
图三： 测试计划中使用的默认>
26 增加>
现在我们需要增加>
1 选中可视化界面中左边树的Thread Group节点，单击右键，选择Add'sampler'>
2 他的参数和25中介绍的>
我们现在增加两个>
图四：设置好的jsp测试请求
图四：设置好的jsp测试请求
图五：设置好的Servlet测试请求（带参数）
图五：设置好的Servlet测试请求（带参数）
27 增加Listener
增加listener是为了记录测试信息并且可以使用Jmeter提供的可视化界面查看测试结果，里面有好几种结果分析方式可供选择，你可以根据自己习惯的分析方式选择不同的结果显示方式，我们这里使用表格的形式来查看和分析测试结果。你可以通过下面的步骤来增加listener：
1 选中可视化界面中左边树的Test Plan节点，单击右键，选择Add'listener'view result in table，界面右边将会出现他的设置信息和结果显示框。
2 你可以设置界面上面的filename属性设置将测试结果保存到某个文件中 界面下面将使用表格显示测试结果，表格的第一列sampleno显示请求执行的顺序和编号，url显示请求发送的目标，sample－ms列显示这个请求完成耗费的时间，最后的success列显示改请求是否成功执行。
界面的最下面你还可以看到一些统计信息，最关心的应该是Average吧，也就是相应的平均时间。
28 开始执行测试计划
现在你可以通过单击菜单栏run -> Start开始执行测试计划了。下面这两个图是作者第一次、第二次执行该测试计划的结果图:
大家可以看到第一次执行时的几个大时间值均来自于jsp request，这可以通过下面的理由进行解释：jsp执行前都需要被编译成class文件。所以第二次的结果才是正常的结果。
根据下面步骤创建适应业务需求的云数据库Redis版实例。
使用下列方法中任意一种打开购买页：
打开云数据库Redis版产品首页，单击立即购买。
说明 如果尚未登录阿里云账号，单击立即购买后需要先使用阿里云账号和密码登录。
登录Redis管理控制台，单击右上角的创建实例。
设置以下参数。
选择密码设置方式。
立即设置：在下方的输入密码区域设置密码。
稍后设置：创建实例后再修改密码。
设置实例名称、购买数量，如果创建包年包月实例，还需设置时长。
在确认订单页，阅读《云数据库KVStore版服务协议》，确认接受后在服务协议前的选框中单击勾选。
单击去开通。
因为这方面内容较多，这里也写不开那么多内容，所以你可以留言或到我的博客上搜索相关内容，老魏有写过教程，还不止一篇，都挺详细的内容，可以帮助你入门。
1、硬件性能不足，检查服务器的配置，如果您服务器配置一直没有升级，而程序的占用一直在加，是要可能导致服务器运行速度变慢2、系统方面检查，杀一下毒，看服务器是否有中毒没有
3、重启一下服务器，服务器长时间运行，里面占用资源越来越多，您可以重启一下清除一下缓存压力
4、带宽方面，可以检查一下目前服务器所接入的带宽，再对比一下服务器平常使用的带宽情况，如果是带宽不足导致，升级一下带宽就可以解决
这个脚本是经常用来测试服务器性能尤其是Ubunut1604的，在购买vps之后可以用来测试一下性能
对服务器信息、CDN加速节点的Speedtest测速、各大洲节点的Speedtest测速、IO测试进行全面测试
只对服务器信息、CDN加速节点的Speedtest测速、IO测试进行测试
右上角设置->高级->系统->打开您计算机的代理设置->连接->局域网设置->勾选“为LAN使用代理服务器”->地址输入：127001->端口输入：8888->勾选‘’对于本地地址不使用代理服务器->确定。PS：设置代理时要关掉抓包工具，因为它也是一个代理服务器。
注：jmeter自带代理服务器
1、设置代理
启动Jmeter->测试计划->右键添加“非测试元件”->选择>针对问题：CPU利用率可以建模平均能耗，但是对于预测峰值粒度过粗。
提出模型：表征服务器利用率和电源行为之间的关系，对实际峰值功耗建模。引入新的 *** 作系统指标，捕获所需信息，以较低的开销设计峰值功率。
如今，数据中心运营商普遍以几十分钟到几小时的采样间隔收集实用跟踪信息。 由于存储和处理的开销，对成千上万的服务器禁止更细粒度的采样。 例如，对于1000个节点的群集，以OS调度程序的粒度（100Hz）采样将每周产生225 GB数据。
要确定服务器的峰值功率，就要了解服务器 开关模式电源单元（SMPSU插座式电源） 的行为。这些设备效率很高，但是依赖于开关和电荷存储机制，从而将 RC（电阻-电容）行为 引入了功耗。我们的贡献是将服务器的 *** 作系统视图与电源能耗峰值相连接。
介绍一个易于采集的 *** 作系统级别的度量（30ms），该度量可确定一段时间内的峰值功耗。通过模型合并SMPSU的RC行为，并以较低的开销跟踪峰值功率。这种机制可以记录随时间变化的峰值功率，并有助于大规模数据中心能耗供应研究。
贡献：
说明了以细粒度采集利用率所面临的挑战，以及峰值和平均度量之间的重要差异。
服务器开关电源单元的特性及其能耗与服务器利用率之间关系的解析信号处理模型。
一种新的 *** 作系统级度量标准，可捕获峰值功率信息以用于服务器检测。
通常PDU会被过度配置，预配置容量远高于平均负载。
功率上限power capping是一种数据中心级别的技术，可以对服务器的峰值功耗（例如，使用控制回路）进行硬限制。节流服务器电源DVFS（通过频率/电压缩放）用作安全机制，以确保不超过最大功率水平并且断路器不跳闸。使得PDU和其他电源供应基础架构就可以得到超额订购，从而降低了有效的资本成本。由于负载/功率峰值很少，因此节流性能几乎没有损失。通过使用电源路由可以进一步降低资本成本，这可以在负载不平衡时在PDU之间转移负载。
所有这些技术都需要软件机制来跟踪和预测峰值功率，以管理每个服务器，电路和PDU的功率预算，同时最大程度地降低性能节流。尽管可以通过显式计量和记录来跟踪峰值功率，但是直接从 *** 作系统级别的指标评估峰值功率可以大大降低成本。要从 *** 作系统级别的指标推断和记录峰值功率，我们必须了解服务器电源的 *** 作及其与利用率的关系。
服务器中SMPSU设备的行为以及其与OS观察到的利用率的关系。
研究对象： 两种不同的系统：具有便宜商品PSU（“商品”）的小型系统和具有企业级PSU（“服务器”）的大型系统。 由于SMPSU的设计不同，这些系统在行为上存在一些差异。 但是，与预测峰值能耗方面相似。
商品PSU的峰值传输电流比服务器更明显。 这种差异是由于在高端设备中常见的第一级额外开关调节，用于产生更连续的电流。
使用工作负载SQUARE观察 利用率 变化 频率 的影响。使内核在 矩阵乘法 与处理器 空闲模式 之间切换，使系统利用率产生方波。工作负载的 占空比（占空比是指在一个脉冲循环内，通电时间相对于总时间所占的比例） 固定为50％，平均利用率为50％。改变方波的频率，并观察PSU的响应。
使用工作负载STEP表征 利用率变化和PSU响应之间的延迟 。使系统处于空闲状态，等待直到PSU行为达到稳定状态。然后在所有内核上进行矩阵乘法。由于无法直接从外部观察CPU利用率，因此在过渡到在示波器上开始计时之前立即发送了一个信号（使用比预期的SMPSU响应快得多的通用I / O）。
图5表明：调制频率对观察到的功率波形有很大影响。 只要对CPU的利用率进行缓慢调制，功耗的包络就大致类似于方波，与CPU的行为相匹配。 然而，随着频率增加，功率消耗变得更加均匀。
对SMPSU峰值进行建模，以细粒度（在许多系统的内核调度间隔附近）监控利用率。
使用STEP工作负载研究SMPSU电源负载的相位延迟。 瞬时功率响应存在一个延迟，该延迟随着RC滤波的阶跃函数的期望而增加。 图示利用率转换的I / O信号（“trigger”）以及隐含的利用率波形（“ Utilization”）。 最后，我们显示了一个已过滤（“filter”）的阶跃函数，该函数适合观察到的上升波形。 该信号由具有界限频率30 Hz的一阶RC滤波器产生。
低于20HZ的更细微的变化会被电源的RC行为过滤掉，因此不考虑。 通过对SMPSU的运行及其与服务器利用率的关系的新了解，我们构建了一种开销低的方法，可以从 *** 作系统内核的利用率中推断出峰值功率。 然后，我们使用真实的机器验证我们的模型，并表明我们可以预测峰值功率曲线，且误差低于20％。
实验设置：两种服务器配置验证能耗模型。
在系统执行Linux内核的并行编译时收集能耗，该工作负载产生了混乱的突发使用模式。
瞬时能耗（“实测”）。预测能耗（“ Predicted”）很好地跟踪能耗峰值，但有时能耗仍然超出预测值。 幸运的是，该模型趋于保守，并且高估的能耗多于低估的能耗。 因此，它将在例如功率预算/封顶研究中提供保守估计。 商品计算机和服务器计算机的标准化均方根偏差（NRMSD）分别为14％和19％。
总结
1使用CPU利用率对服务器的峰值功耗建模。
2描述了OS级利用率与现代服务器中SMPSU行为之间以前被忽略的关系。
3通过测量真实的服务器PSU，证明必须以 33 ms或更低的粒度监视利用率以预测峰值功率 。 我们基于轻量级PSU的RC行为的信号处理启发模型，介绍了OS级解决方案，并演示了峰值功率可以近似在20％的NRMSD之内。SQL2005安装过程提示com+目录问题警告处理
安装sql2005一直失败,以为提示的问题是这个com+目录问题警告所致,找了很久找到这个问题的解决方案
sql2005_STD_X86在WINDOWS 7下安装失败的一点经验
软环境是WINDOWS 7旗舰版，安装SQL2005_STD_X86版。
故障提示：
1。 如果 SQL Server 安装程序失败，安装程序将回滚所安装的系统，但可能不会删除所有 manifest 文件。解决方法是重命名这些文件，然后重新运行安装程序。有关详细信息，请参阅“如何处理 SQL Server 安装过程中的 COM+ 检查失败问题”。如果未运行 Microsoft 分布式事务处理协调器 (MS DTC)，或者，在使用 Microsoft 群集服务器的情况下，如果 MS DTC 不是群集资源，则可能会发生 COM+ 错误。COM+ 依赖于 MS DTC，而 Integration Services 中的消息队列任务依赖于 COM +。如果出现 COM+ 错误，则只有将 COM+ 系统正确配置后，Integration Services 中的消息队列任务才可用。
2。对性能监视器计数器注册表值执行系统配置检查失败。有关详细信息，请参阅自述文件或 SQL Server 联机丛书中的“如何在 SQL Server 2005 中为安装程序增加计数器注册表项值”。
安装中止。
查找联机丛书，有如下提示：
1。Microsoft SQL Server 2005 安装程序检查 COM+ 是否已正确配置。如果发现配置错误，安装程序仍将继续，但是在系统配置检查 (SCC) 报告中显示以下警告：
“如果 SQL Server 安装程序失败，安装程序将回滚所进行的安装，但可能不会删除所有的 manifest 文件。解决方法是重命名这些文件，然后重新运行安装程序。”
如 果未运行 Microsoft 分布式事务处理协调器 (MS DTC)，或者，在使用 Microsoft 群集服务器的情况下，如果 MS DTC 不是群集资源，则可能会发生 COM+ 错误。COM+ 依赖于 MS DTC，而 Integration Services 中的消息队列任务依赖于 COM +。如果出现 COM+ 错误，则只有将 COM+ 系统正确配置后，Integration Services 中的消息队列任务才可用。
若要使用消息队列（亦称 MSMQ），请确保 MS DTC 正在运行并且已正确配置。如果 SQL Server 安装在群集上，则 MS DTC 必须是群集资源。
按照下列过程重新安装 COM+。
安装组件服务管理单元
在 Windows 桌面上，单击“开始”，然后单击“运行”。
在“打开”框中，键入 MMC，然后单击“确定”。
在“控制台”窗口中，单击菜单栏上的“文件”，然后单击“添加/删除管理单元”。
在“可用的管理单元”中选中最后一项“组件服务”，单击右侧的“添加”按钮。
然后单击“确定”以关闭“添加/删除管理单元”窗口。
在“控制台根节点\组件服务”窗口，展开“组件服务”树。这就是当 COM+ 出现问题时，错误消息可能发生的地方。
再次运行 SQL Server 2005 安装程序。如果收到错误消息，请重新安装 COM+。
重新安装 COM+
从控制面板的“添加或删除程序”中，单击“添加/删除 Windows 组件”。
在“Windows 组件向导”中，不对选择做任何更改，单击“下一步”。
一直单击以完成向导，然后再次运行 SQL Server 2005 安装程序。
2。在 SQL Server 安装开始前，Microsoft SQL Server 安装程序中的安装配置检查器 (SCC) 会验证计数器注册表项的值。如果 SCC 无法验证现有的注册表项，或 SCC 无法运行 lodctrexe 系统程序，则 SCC 检查会失败，致使安装受阻。
错误编辑注册表会严重损坏您的系统。更改注册表项之前，建议您备份计算机中的所有重要数据。
手动设置计数器注册表项的增量
在 Microsoft Windows 7中依次单击“开始”、“运行”，然后在“打开”中键入 regeditexe，再单击“确定”。定位到以下注册表项：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib]
"Last Counter"=dword:00000ed4 (5276)
"LastHelp"=dword:00000ed5 (5277)
上 一步的“Last Counter”值 (5276) 必须与以下注册表项中“Perflib\009”的“Counter”项的最大值匹配，并且上一步的“Last Help”值 (5277) 必须与以下注册表项中“Perflib\009”的“Help”项的最大值匹配。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009]
注意 009 是英文中的一个示例。“Last Counter”和“Last Help”值是由 Windows 动态分配的；这两个值会因计算机的不同而不同。
如 有必要，可修改“\Perflib”项中的“Last Counter”和“Last Help”值的值：在右侧窗格中，右键单击“Last Counter”或“Last Help”，单击“修改”，再单击“Base = "Decimal"”，在“值数据”中设置值，再单击“确定”。如有必要，对另一个项重复以上过程，然后关闭注册表编辑器。
再次运行 SQL Server 安装程序。
解决过程：
COM+ 检查失败不用说肯定是组件消息队列下的组件没安装或服务没启动。本机没有安装过消息队列，找出系统盘安装消息队列组件，在组件安装中提示MSDTC服务没 有启动，在这步晕了长很时间，MSTDC在服务中怎么也找不到，后来想会不会是DTC（脑子有点笨，其实从MSMQ这名称上就应该想到），一看果然有 Distributed Transaction Coordinator（DTC），但是这个服务启动不了，后来查找相关资料：MSDTC( Distributed Transaction Coordinator )服务必须在 NT AUTHORITY\NetworkService 帐户下运行；即使是 NT AUTHORITY\Network Service（注意，Network和Service中间有空格）也不行（至于这两个帐户的区别，在网上也没有找到，还望大家不吝赐教 ）。如果登录帐户被更改，MSDTC服务会继续运行，但是在执行的时候可能会出错。而且，在事件日志的“应用程序”里面可以发现如下的出错信息：
正 在运行 MS DTC 服务的帐户无效。 如果使用 Microsoft Management Console (MMC) 中的“服务”管理单元更改了服务帐户信息，就会发生这种情况。 MS DTC 服务将继续启动。请确认使用“组件服务管理器”更新了 MS DTC 服务帐户信息。
要更改成正确的登录帐户，我们可以：
在服务中找到Distributed Transaction Coordinator服务，选择“属性”；
在“登录”选项卡中，选择“此帐户”，帐户名填写“NT AUTHORITY\NetworkService”，密码为空；
在点击“确定”后重新启动服务。
或者，在命令行下运行 msdtc -uninstall ，卸载 msdtc 服务；
再运行 msdtc -install ，安装 msdtc 服务。
MSTDC服务成功启动，组件服务中“COM+应用程序”可以访问，上面第2项故障没去解决，先试着安装看看有没有错误，令人惊喜，安装检查一切顺利，第2项错误同时也解决了。
当然，解决问题的过程同样的系统环境也不尽相同，在这里谈一下我安装的小挫折，希望可以给碰到相同问题的朋友有些提示作用。
另外,虚机团上产品团购,超级便宜
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）