服务器性能测试工具，怎么测试香港服务器访问速度

第一种方法备案域名：常见的ping命令服务器性能测试工具。服务器性能测试工具，怎么测试香港服务器访问速度这个命令与IT打交道的站长并不陌生，一般来说，网站速度不好，或者测试一下是网站问题还是服务器问题，都会使用这个命令进行测试。那么具体怎样检测租用服务器的网络是否通畅无延迟呢？在电脑中点击开始，运行，然后输入CMD打开DOS命令窗口。然后输入网站网址，或者服务器的IP地址，格式为ping 域名，或者ping IP。使用ping命令后，会反馈一个结果，这个结果基本包括了以下几个信息。第二种方法：tracert命令。测试方法与ping命令类似，只是将ping 换成tracert，不过这个命令可以用来检测终端用户到服务器机房的跳数及响应时间，换句话说，就是可以测试出服务器与全国客户的连接速度。显示时间也是以Ms为单位，时间越短越好。第三种方法：比网站加载速度。可以利用WhichLoadsFasterFastSoft工具测试一下打开网站速度。基本工作原理是通过连接，在浏览器中让两个真实的网页显示出来，反应的结果就是两个网站真实打开速度对比。第四种方法：网站速度测试工具。使用GTmetrixgtmetrix有丰富的测量结果，能够提供相关的网站速度提升建议，站长可以根据这些建议优化站点。然后再逐一找到加载速度变慢的原因。目前主流好用的性能测试工具主要可以分一下几类：1.简单的接口url压测apache ab：相当简单的压测工具了，只要一台Linux机器安装好ab就可以使用了，用法也非常简单，一条命令就可以了，适合对压力要求不高，压测场景简单的压测。wrk：类似ab的压测工具，适合前端页面压测，比ab略强些。2.主流的大压测Apache Jmeter：这个必须排第一，当前最流行的开源压测工具，功能非常强大，可以实现非常复杂的场景，基于JAVA语言，可以多机远程并行施压，有丰富的图形结果展示，并支持大量插件扩展。gatling：基于SCALA，可模拟大量并发，号称比jmeter厉害，缺点是不支持多机并行压测。grinder：基于Python，类似jmeter，熟悉Python的可以用这个。tsung：比较另类的压测工具，需要特定的运行环境，操作复杂。3.商用类LoadRunner：大型商用压测工具，基于C语言，非常贵。4.其他各类压测平台xmeter、淘宝性能测试平台、腾讯性能测试平台等等，费用也是相当高，而且并不能满足复杂场景。翻到一篇以前写的旧文，可以回答这个问题。在当前的下一代防火墙产品测试过程中，网络应用性能测试已经得到了充分的重视。然而在产品适用性分析上还有很大的不足。用户不清楚如何对产品各种应用性能指标进行理性的辨别，只能以性高则优的方式去进行选择。厂商也因此，不得不陷入产品性能价格比拼残酷竞争之中。如何摆脱性价比之争，令产品选择回归理性？这就需要一个由应用到适用的转变。什么是适用评估在以往的网络产品测试中，我们仅关注网络产品的处理性能，而缺乏对用户网络应用需求的分析。因此在实际应用过程中，常会出现采用高性能产品成本增加，低价格产品适用能力不足的情况；高性能低价格的产品也有，可往往又会有产品质量隐患出现的问题出现。因此，用户采购网络产品时，往往需要大费心力。要想缓解此类情况，理想的办法，就是让厂商主动将其网络产品的适用性做一下评估。什么是网络产品适用性评估？简单说，就是找到用户网络产品处理性能可忍受的底线，并以此为基准，对网络产品处理性能进行分析。举个较常见的例子：当对一条接入宽带的服务质量做适用性评估时，首先我们需要对接口带宽的数据包转发性能评估，看其是否可以在满足正常数据转发时，对带宽流量不产生影响。其次，对连接处理能力进行分析，了解其可以满足多少用户同时使用，连接处理不产生瓶颈。这只是对网络产品，对网络安全产品，适用性评估需要考虑的问题会更多。适用评估要如何进行也许有人会存有疑问，这些种分析看起来并不复杂，以前没有人在做吗？在这里十分遗憾的告诉大家，至少是没有很好的去做。为什么？因为目前为止，还没有一个较通用的网络适用性评估标准。目前为止，我也只是在个别大厂商的产品评测中，试着去进行一下产品适用性的评估分析，但这还远未达到生成一套普遍认可的网络适用标准的地步。而且用户网络应用的需求又是因人而异，并随应用变化面变化。因此网络适用性标准的建立举步维艰！那么我们就不去做适用性评估了吗？不，饭要一口口的吃，事要一件件的去做。想当年网络应用性能测试的各项指标，也是从无到有，从一份报告一个厂商开始，逐渐在厂商和用户中普及并得到认可。现在网络适用性评估，只要我们坚持不懈，相信也会有普及的一天。我现阶段的工作计划如下：由于下一代防火墙的各项功能指标在网络层及应用层中均有覆盖，非常具有代表性。因此计划通过下一代防火墙测试方法的研讨，并与相关测试仪表厂商和产品厂商进行沟通，对下一代防火墙的适用性评估技术指标项目进行制定，并明确每个指标的具体测试方法。再通过广泛接触厂商及最终用户的方式，对适用性评估的媒体评估标准进行确定。期望通过若干次的试定修改，相信会有一个比较成熟的网络适用性评估方案可以出台。适用评估方法现在，就根据以往的测试经验，将需要评估的技术指标进行一下罗列：具备下一代防火墙产品的厂商众多，各个厂商的下一代防火墙功能也不尽相同。为了方便统一、规范化的进行分析，现在计划通过网络层适用评估、传输层适用评估、应用层管理控制适用评估、应用层深度内容分析适用评估这四个方向，对下一代防火墙的适用性进行分析。网络层适用评估基于网络层数据包的转发管理控制测试，可以说是最基础的网络测试项目。RFC 2544的相关测试项至今依然适用，只不过测试项目已精减到了目前的吞吐量和时延这两项而已。网络层适用评估适用于下一代防火墙产品中的传统防火墙功能、路由转发功能、NAT以及透明模式下网络接口数据包转发性能评估。评估指标项目前暂定为吞吐量和时延。吞吐量有关吞吐量的适用评估，我在思科的ASA 5500X防火墙测试中进行了一次分析，这里就不再赘述了，有兴趣请参阅评测文章“演进中的下一代”中“稳健可靠的网络传输”/test-report/htm2013/20131112_286063_2.shtml中的相关描述。在那里，我依据思科反馈的在不同应用场景下数据包平均大小统计，将吞吐量指标的合格线定在了512Byte时吞吐量达到或接近100%即可满足用户应用需求。下一步将依据此项评估指标再与其它下一代防火墙厂商和用户进行沟通，收集更多应用需求后再次进行确定。时延从我个人应用体验来看，数据链接建立的最大时延只要不超过1000毫秒（1秒），基本上可以忍受，但在数据传输时的平均时延就不同了，最好在1毫秒以下否则数据传输速率会受到较大影响。现在进行测试时，时延所采用的数值通常时整个数据传输过程中所有数据包传输的一个平均值，这里时延指标的高下就有一些参差不齐了。个人感觉，平均时延如果能在50毫秒以下，应用时应该不会有太多传输问题出现。当然，时延的指标还是越小越好，具体指标同样还需要继续与厂商进行沟通。传输层适用评估在实际网络应用中，一个传输层连接内有多个应用连接，或一个应用会发起多个传输层连接的情况均十分常见，因此以往的应用性能测试中，传输层应用性能测试项目常常被忽略，或与应用层处理性能相混淆。而随着下一代防火墙连接管理控制功能逐步受到重视，以及未来SDN交换设备的大规模应用，此项测试的重要性也将得以突显。以往对传输层性能测试的方法也与应用层测试差别不大，都是采用应用层的网络测试仪表，通过建立TCP协议传输通道的方式来考查被测设备的传输层连接建立能力和连接保持能力（TCP新建连接和TCP并发连接）。这里就会出现一个问题，当前网络及网络安全产品传输层的处理能力在显著提升，而测试仪表的测试性能开始出现瓶颈。前些时间接到一个测试，一个1U网络产品，传输层的处理性能（数百万的新建性能！）预计需要4-5台高性能应用层测试仪表才可能满足测试需求。这种情况的出现，不但为测试机构，同样也为厂商对产品的性能验证提出了更大的挑战。可以预计，当未来SDN交换机产大规模出现后，如果传输层测试方法没有很好改善，将会有更多的相关测试问题出现。为改善这种被动情况，必需对测试方法进行改进。在这里我准备与测试仪表厂商（思博伦和IXIA）进行进一步沟通，试着采用网络层测试仪表在数据包中加入UDP头信息的方式对传输层处理性能进行验证。然而这里会牵扯到连接协议建立是否完整的问题，还需要再进一步与厂商就测试方法进行沟通验证。下面就传输层适用评估指标进行一下分析：TCP（或UDP）新建连接有关传输层适用性的评估指标，根据我个人总结的情况来看，在传输层连接建立能力（TCP或UDP新建连接）指标评估时，单用户（每IP）最低可忍受1Mbps带宽、每秒钟建立10个传输层连接的新建连接处理性能。因此，就暂将单用户（每IP）1Mpbs带宽、每秒10TCP（或UDP）新建连接做为传输层新建连接的适用层评估指标TCP（或UDP）并发连接同样还是当前我个总结情况，每个用户（每IP）最少保持100个TCP（或UDP）连接既可保单个用户的最小网络应用需求。在今后参与厂商具体产品测试过程中，我还将根据具体情况对此指标进行进一步修订，并以此为基准对厂商产品传输层处理能力进行评估分析。应用层适用评估下一代防火墙最重要的转变就是具备了网络应用行为分析能力，在未来势必因此而引发网络安全防护的重大变革。相关分析可参考我的另一篇下一代防火墙分析及测试方法探讨文章“网络安全能否做到夜不闭户”。（/test-news/htm2014/20140826_311052.shtml）而应用性能自然也成为用户选择下一代防火墙产品的关注重点。根据目前所掌握情况来看，下一代防火墙产品的应用层性能测试，还没有类似传输层测试仪表性能瓶颈的情况出现。但并不是说现在的应用性能测试项目就可以满足下一代防火墙功能测试需求。理由有以下两点：一、单一应用协议对应用处理性能无法全面评估目前传统应用层性能测试仅通过}二、混合应用流量协议不规范十年前开始进行网络应用性能测试时，应用协议模拟数量少，而且其它协议（FTP、SMTP等）所占应用比例也小，因此的应用性能测试标准，增加混合应用流量测试的新方法。对于这点我肯定是会举双手赞成的。但在这个标准出台之前，还是再和测试仪表厂商协商一下相关测试方法的事情吧。不过旧指标不是一下就可以轻易抛弃的，通过}下面就应用层适用评估指标进行一下分析：}由于传输层协议已经把管道的数量进行了限制，在这个管道里再跑什么应用也就是下一代防火墙再做一下深入分析的事情了。因此）1Mpbs带宽、每秒10 }并发连接数同上，目前也是定在每个用户（每IP）最少保持100个}应用流量从当前下一代防火墙产品功能性分析上来看，只有在下一代防火墙进行深度内容识别（例如开启IPS、文件内容检测或防病毒功能）时，才会对应用文件内容去进行分析。这时，应用流量的性能评估才会有意义，否则通过网络层数据包转发性能对流量转发性能进行测试就足以了。而对传统的应用流量转发性能测试时，测试方法单一、死板。同样也是仅采用新建连接速率下，加载一个固定大小文件来生成一个较大测试流量。从上次下一代防火墙测试中可以了解，这种测试方法已经无法满足当前产品在进行深度内容识别时，流量处理能力的测试需求。现在测试仪表厂商有两种不同的新应用流量测试方案。一种是采用抓包回放的方式模拟真实网络流量，一种是用测试仪表直接生成多种应用协议测试流量。这两种方法各有利弊，抓包回放数据流与真实应用情况相近，但生成大流量比较困难；测试仪表生成多种应用协议测试流量可以满足，但应用文件内容定制不便。看来此项测试还需要再和测试仪表厂商多多进行沟通才可以有一个比较明确的测试方法出台。明确应用需求 保住适用底线以上适用评估测试方法，很多是很早以前就有的，在这里反复炒冷饭的原因就是，通过适用性的基础指标乘上使用人数，用户可以轻易了解，自身对网络设备的实际应用需求。从而可以更加明确的去选择产品。对于产品厂商也同样是如此，厂商提供设备的网络应用处理能力在这条低线之上，即可保障用户最起码的网络正常应用。当然用户经济能力以及厂商技术能力允许，也可以选用性能更高、处理能力更强的产品来对网络业务应用处理能力再进行提升。我也会在以后的产品测试报告中，同样引入适用性的指标对厂商产品性能进行评估。从而选出更加适合用户选用的优质产品出来以供大家选择。本文来自科技行者团队老董