文章编号：36406 / 分类：行业资讯 / 更新时间：2024-12-13 04:12:50 / 浏览：次

简介

服务器负载测试是软件测试中至关重要的一步，旨在评估服务器在大量并发请求下的性能。它有助于识别瓶颈、确保应用程序的可扩展性和稳定性，并预测高峰流量时的系统行为。

入门指南

1. 定义测试目标

明确测试目的，例如确定服务器容量、识别性能瓶颈或验证可扩展性。

2. 选择负载测试工具

选择满足您的测试需求的负载测试工具，考虑因素包括：支持的协议和技术同时模拟的用户数量场景和测试数据创建功能报告和分析能力

3. 创建测试场景

定义模拟真实用户交互的测试场景，包括：请求类型（例如 HTTP GET/POST/PUT 等）请求频率和并发水平测试数据和变量

最佳实践

1. 选择现实世界的负载模式

根据预期的真实用户流量模式设计负载测试。避免简单地模拟恒定负载，而应该考虑高峰和非高峰时段。

2. 监控关键指标

在负载测试期间，监控以下关键指标：响应时间吞吐量（每秒请求数）错误率资源利用率（CPU、内存等）

3. 逐步增加负载

逐渐增加负载以识别性能瓶颈。从较小的并发水平开始，并逐步增加负载，直到达到预期高峰流量。

4. 探索不同场景

运行不同的测试场景以覆盖各种用户行为。这有助于发现系统在不同情况下的性能。

5. 分析结果和优化

仔细分析测试结果，识别瓶颈并制定优化措施。可以考虑优化数据库查询、调整服务器配置或实施缓存机制。

6. 定期进行测试

在应用程序开发和维护周期中定期进行负载测试。这有助于确保系统在不断变化的负载下保持性能。

结论

服务器负载测试是软件测试中一项必不可少的实践，有助于确保应用程序的可扩展性、稳定性和性能。通过遵循这些入门指南和最佳实践，您可以有效地执行负载测试，获得有价值的见解并改进您的应用程序。

---

接口测试，负载测试，并发测试，压力测试的区别

接口测试的目的是通过检查数据交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系，更早地发现问题，缩短产品周期，发现更底层的问题。 接口测试通常通过接口测试工具进行，检查接口的各种参数、请求头、请求体、响应和响应头是否符合要求规范。 负载测试的目标是检测系统运行的最大上限，确保在最大压力下系统能够正常运行，并获取系统指标。 实现负载测试的方法是逐步增加系统负载，直到服务器某个资源项达到饱和或某个指标达到安全临界值。 系统负载压力包含并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的关键指标。 并发测试的主要目的是检查系统是否有并发问题，例如内存泄漏、线程锁、资源争用等问题。 进行并发测试的方法是确定用户并发数，即系统所承载的在线用户数。 然后在单位时间内（S）同时发起一定量的请求。 确定并发用户数的方法需要考虑实际在线用户的分布情况，确保能准确反映服务器压力。 压力测试的目标是查看系统在极限情况下可以运行到何种程度，发现性能缺陷。 压力测试通常基于负载测试或并发测试的结果，通过给软件不断加压，使其在极限情况下运行，观察系统性能的极限点。 通过压力测试，可以了解系统能够承受的最大并发量，以及在达到特定并发量时系统的行为，从而发现性能瓶颈和潜在问题。

如何对API进行负载测试与调优（一）

本文由Donny译自 的 《How to load test & tune performance on your API》这几年API的作用不断演化，以前API还只是用来做内部系统之间的集成点，但现在API已成为一个公司的核心系统，一个构建于Web和移动端应用之上的核心系统。 当API仅只用来处理后台的任务（例如生成报告），那么性能差点也不是问题。 但是如今API慢慢地发展成为连接服务与终端用户的核心纽带。 这种关键性的角色变化表明了一个重要的观点：那就是API的性能真的很重要。 如果API数据源响应快，前端的应用程序的设计好点或差点影响不大，要是响应慢如蜗牛，前端的设计再出色也是然并卵。 现在我们的客户端应用展示的数据源可能都是来自多个API响应内容的聚合，性能对这种微服务构架来说真的非常重要。 可以毫不夸张的说出色的性能就是你API提供的最好功能。 我们知道向目标改进的唯一正确的方法就是找到问题的关键点，或者叫关键路径，并不断迭代测量和调整你的架构系统，直到系统达到预定的目标。 对于API来说，测量和提高性能的过程就是负载与压力测试的过程。 本文将重点介绍如何对你的API进行负载压力测试。 我们会以一个简单的、未测过的例子开始，然后再添加一个访问控制层，要确保一切都经过严格测试，做好处理真实流量的准备工作。 OK，开始吧！首先我们要明确要测试什么，可以是对你所有的API接口，或者是对单个API接口，或是对需要排除故障或改进的API接口的常规测试。 本文的其部分，我们将使用一个示例API。 这是一个棋牌类游戏的 API。 它有三个API接口：/question – 返回一个随机黑牌 /answer – 返回一个随机白牌/pick – 返回一对随机的问题与答案 你测试用的负荷情况越和真实环境的越类似，你的负载测试就越有用。 如果你不知道实际流量有多少或者你不知道负载在所有接口上是否都一致，那么就算你知道你的API可以保持400 请求/秒的吞吐量也没啥鸟用。 所以，你应该先从收集你API的使用数据开始。 你可以直接从你的API服务日志或者从其他你在用的应用性能工具（例如New Relic）中获取数据。 在对你的API进行第一次测试之前，你应该对以下问题做到心中有数：（1）每秒请求数的平均吞吐量（Average throughput in requests per second） （2）峰值吞吐量（您在某段时间内获得的最大流量是多少？）（Peak throughput） （3）API各接口的吞吐量分布情况（有没有一些接口的流量远超其他接口？） （4）用户的吞吐量分布情况（少数用户产生大多数的流量，或者是更均匀分布？） 另外还需要考虑的一个关键点是，在测试期间将要模拟的流量会是怎样的，主要考虑点是： （1）重复负载生成（Repetitive load generation） （2）模拟流量模式 （3）真实流量 通常我们最好以最简单的方法开始测试，然后逐步演化到更为接近真实环境的测试。 我们可以先用重复负载生成来做为API接口的第一个测试，这样不仅可以验证我们的测试环境是否稳定，更重要的是可以让我们找到API能承受的最大吞吐量，这样我们就可以知道API可以达到的性能上限是多少。 找到你的API性能上限值后，你就可以开始考虑如何将你的生成的测试流量塑造得更接近真实环境。 使用真实流量来测试是最理想的，但实际操作不太可行。 要模拟真实流量比较难，也太花时间。 所以我们有一个折中点的方法：先研究你的流量分析数据，并做一个简单的概率模拟。 比如你有100个API接口（提示：原文endpoint在这里我译为接口，翻译成端点也可以，不过译成接口感觉更容易理解），你检查了上个月的使用情况，发现80%的流量来自20个接口，其中3个接口占用了50%的流量。 那么你就可以创建一个遵循这种概率的请求列表，并提供给你的负载测试工具。 这样做就相对快多了，并且它相对比较接近你真实负载，可以显示出你实际环境中可能遇到的问题。 最后，如果你拿到你要测试的API的真实访问日志，你就可以用它们来做最接近客观现实的测试。 我们待会儿要讨论的大部分负载测试工具，都是接收一个请求列表作为输入文件。 你可以用你的访问日志，稍微做一个格式调整就可以匹配每个测试工具所需的格式。 搞定这个你就可以在测试环境中轻松重现你的生产流量。 好了，你清楚了你要测试什么鬼了，准备工作的最后一步就是配置好你的测试环境。 你需要一个专用的测试环境。 如果你不怕被你老板骂的话，或者比较任性，你也可以直接在你的生产环境中进行性能测试，不过出问题别说哥事先没跟你说清楚哈。 如果您已经设好一个预生产或沙箱环境，并且你的API也在上面运行了，那么你就万事俱备了。 因为本文要用示例API，我们会在AWS的服务实例上设置我们的环境。 在我们的例子中，我们使用一个简单的API，不需要从磁盘读取或在内存中保存大型数据集。 我们选择 实例就够了。 注意：我们对比过其他相似处理资源数但内存更大的AWS实例，但实际测试中内存大部分没使用，所以我们选了 接下来，我们将一个配好的负载测试实例（服务器）运行起来，这只是一个运行模拟测试程序的服务器，它会通过从多个并发连接重复发送请求到我们的API服务器。 你需要模拟的负载越高，机器的性能就要求越高。 再次，这也是一个CPU密集型工作负载。 这里我们选择具有4个虚拟核，16个 ECU的优化处理器的 服务器 我们选择在相同的可用区内部署所有实例（API服务器与测试服务器在同一个区/机房），这样可以将外部因素对我们测试结果的影响降到最小。 我们有一个沙箱环境来运行我们的API，同时也有另一台服务器准备开始负载测试。 如果这是你第一次做性能测试，你一定会想知道什么是最好的方法。 在本节中，我们将会分享我们如何选择工具，同时也会介绍一下目前市面上一些公认比较好的工具。 JMeter 在人们意识当中，首当翘楚的估计是 Apache JMeter ，这是一个开源的Java程序，他关键的特性就是提供一个强大而完善的创建测试计划的GUI。 测试计划由测试组件组成，测试组件定义了测试的每一个部分，例如： （1）用来注入负载测试的线程（2）参数化测试中使用的HTTP请求 （3）可添加侦听器，象widget测试组件那样，可以以不同的方式显示测主式结果 优点： （1）它是功能性负载测试的最好工具。 你可以设定条件来为复杂的用户流建模，还可以创建断言来验证行为。 （2）轻松模拟复杂的http请求，比如请求前的登录验证或文件上传 （3）可扩展性强，有很多社区插件可以修改或扩展内置的行为 （4）开源并且免费 缺点： （1）GUI学习曲线陡峭，一大堆的选项，在你运行第一个测试之前你得了解大量的概念。 （2）测试高负载时，操作步骤很麻烦。 你需要先使用GUI工具来生成XML测试计划，然后在非GUI模式下导入测试计划运行测试，因为GUI会消耗掉本用于生成负载的大量资源。 你还需要注意所有的侦听器（收集数据与展示测量的组件）哪些要被禁用或启用，因为它们也很耗资源。 测试结束后后，你需要将原始结果数据导入GUI以才能查看结果。 （3）如果你的目标是测试一段时间内的持续吞吐量（例如在60秒内每秒请求1000次），那么很难找到正确的并发线程数量和计时器来求出一个比较稳定的数值。 JMeter只是我们在开始测试时用的工具，我们很快开始寻找其他替代方案。 原因是，如果你的目标是在Web应用上压力测试复杂的用户流，那么JMeter可能是最好的工具，但如果你只是需要在一些HTTP API接口上进行性能测试，那用它就是杀鸡用牛刀了。 Wrk Wrk 是一款和传统的 Apache Benchmark （最初用来做Apache服务器的测试工具）非常相似的工具。 wrk和ab完全不同于JMeter： （1）一切都是可以通过命令行工具配置和执行的。 （2）配置少但强大，只有基本生成HTTP负载的必要几项配置 （3）性能强悍然而，和传统ab工具相比还是有几个优势的地方，主要是： （1）多线程，所以能利用多核处理器的优势，更容易生成更高的负载 （2）利用Lua脚本很容易进行扩展默认的行为 不好的地方，主要是生成的默认报告在内容与格式上都受到限制（仅文本，无绘图）。 当你的目标是找到你的API可以处理的最大负载量，那么wrk是你最佳选择工具。 wrk用起来很快就可以上手。 Vegeta Vegeta 是一款开源命令行工具，但它采用的方式不同于我们以前所见的工具。 它专注于如何达到与维持每秒请求数速率。 也就是说它侧重在测试支撑每秒X次请求时API会有怎样的服务行为，当你有实际的数据或对你将要达到的峰值流量有个估算时就非常有用，你可以用于验证你的API是否能满足你的需求。 SaaS 工具 正如你之前所看到的，运行一个简单的负载测试需要准备好配置环境。 最近有些产品提供负载测试服务。 我们试过两个， 和 Blazemeter （话外：阿里也有性能测试工具 PTS ，老外估计没试过）。 注意：我们只试了这两个工具的免费版，所以得到的测试结果仅适用于免费版的限定。 Blazemeter 这个产品和我们前面提到的JMeter一样有同样的毛病：如果你只需要用在高负载测试，你需要在GUI界面上创建测试计划，然后在另一个运行非GUI模式的JMeter中导入这些计划。 Blazemeter允许你上传JMeter的测试计划到他们的云端并运行，但可惜的是免费版只能设置50个并发用户。 它是一款 SendGrid 出品的简单而强大的云负载测试服务工具。 它有你所需要的功能和漂亮的可视报告。 的免费版还是不错的，每秒最多可以有次请求的吞吐量，你基本上就可以用它来运行一个真实的负载测试。 我们推荐使用多个工具，以便可以多重检查我们的测试结果，不同的工具有不同的功能与方法，可以更多方面地反映测试结果。 我们先尝试找到我们的API可以承受的最大吞吐量。 在这个吞吐量下，我们的API服务达到最大CPU利用率，同时不会返回任何错误或超时。 这个吞吐量就可作为我们后面测试要用的每秒请求数。 同样，重要的是要注意到：CPU是限制因素之一，但你也还必须清楚地知道哪些资源会成为你API的性能瓶颈。 我们有必要在API服务器上安装一些工具，以便我们在测试过程中监控资源的利用率情况。 我们使用 和 PM2 模块。 我们的应用运行了一个非常简单的HTTP 服务。 是单线程设计的，但为了利用 AWS实例中提供的双核，我们使用PM2的集群功能来运行应用程序的两个工作进程。 由于我们的API是完全无状态的，所以很容易使用PM2的 核心集群模块（PM2在内部直接使用）。 PM2提供的集群功能提供了不错的快捷命令来start/stop/reload应用程序，也可以监控进程。 我们先使用对API进行测试。 以下是持续30秒，每秒10,000次请求的测试结果，次请求是免费版中允许的最大吞吐量。 在测试期间，我们观察到API服务器的CPU处理器在测试期间只有几次达到100％的容量。 这表示我们的API可能还可以处理更高的吞吐量。 我们接下来通过运行wrk进行第二次测试证实了这一点。 我们的目标就是要将我们的API服务器性能推到极限。 wrk -t 4 -c 1000 -d 60 --latency --timeout 3s这里是我们对这个测试做了多次重复测试的结果：Running 1m test @4 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 62.23ms 30.85ms 1.35s 99.39% Req/Sec 4.07k 357.61 5.27k 94.29% Latency Distribution 50% 60.04ms 75% 63.85ms 90% 64.17ms 99% 75.86ms requests in 1.00m, 189.89MB read Requests/sec: .04 Transfer/sec: 3.16MB 结果表明，我们的预感被证实：它达到16,206请求/秒，同时保持合理的延迟，第99百分位只有75.86毫秒。 我们将这作为我们的基准最大吞吐量，因为这一次我们看到了API服务器的最大容量处理能力：我们刚看到用一个简单的方式来找出你的API可承受的最大流量负载，同时在这过程中我们介绍并讨论了我们看到的一些工具。 请继续关注本文的第二部分，我们将介绍如何控制流量，不要让随随便便一个客户端就可以轻松搞跨您的API。 我们将展示如何通过在架构前端添加代理来确保我们的API的性能不受影响。 本文译自： How to load test & tune performance on your API

压力测试和负载测试的区别

性能测试分为两种维度：访问时间和并发量； 负载测试是从并发量维度出发，不断增加并发量的情况下，系统的性能指标； 压力测试是从访问时间维度出发，在并发量一定的情况下，不断增加连续访问的时间，系统的性能指标； 负载测试的目标是测试在一定负载情况下，系统的性能；（这里不关注稳定性，也就是说不关注长时间运行，只是得到不同负载下相关性能指标即可；）实际中，我们常从较小的负载开始，逐渐增加模拟用户用户的数量，观察不同负载下，系统的响应时间，所耗资源，直到超时或关系资源耗尽，这就是所说的负载测试； 压力测试的目标是测试在一定负载的情况下，系统长时间运行时的稳定性。 比如我们经常利用脚本或工具事先吃掉服务器的一部分CPU、内存或带宽等，创造出一定的负载环境并测试此时系统的事务处理能力，响应时间等等。 压力测试尤其关注大业务量情况下长时间运行系统时，系统性能的变化（例如是否反应变慢，是否会内存泄漏导致系统逐渐崩溃）； 打个比喻： 一位服务员，就相当于咱们的应用系统； 负载测试就是在单位时间内逐步加大这位服务器的工作量，看看此服务员在不同的工作量下完成工作的速度和质量，从而了解该服务员的工作能力； 压力测试就是给这位服务员外部压力，比如长时间不让他休息，不给开工资等，看看服务员会不会好好工作（能否及时响应请求），或者罢工之类的；

相关标签： 101、 入门指南和最佳实践、 服务器负载测试、 服务器负载测试、

本文地址：http://www.hyyidc.com/article/36406.html

上一篇：揭开小程序转化率提升的神秘面纱20个鲜为人...
下一篇：利用小程序广告扩大品牌知名度吸引更广泛的...