精华内容
参与话题
问答
  • 负载测试

    2010-11-02 17:20:02
    负载测试(Stress Testing)简介 在实际工作中,负载测试方法和压力测试方法往往被放在一起谈论,因此很容易混淆,其实它们的区别是很明显的。 【负载测试方法】 负载测试(Load Testing)方法通过在被测试...

     

    负载测试(Stress Testing)简介

    在实际工作中,负载测试方法和压力测试方法往往被放在一起谈论,因此很容易混淆,其实它们的区别是很明显的。

    【负载测试方法】

    负载测试(Load Testing)方法通过在被测试系统上不断增加负荷,直到事先选定的性能指标(比如响应时间),变为不可接受或系统的某类资源使用已经达到饱和状态。负载测试方法实际就是一个不断加压,直到找到系统不可用临界点的过程,形象地说,那一点正是"强弩之末"。

    【负载测试方法与举重比赛】

    在5.1.7节我们把压力测试和体操比赛的规定动作相类比,在这里我们将负载测试方法类比为举重比赛,如图5-4所示。在比赛中,选手不断地增加重量,挑战自己的极限,直到杠铃加到某一个重量时,3次试举都失败。这一重量就是举重比赛的最终结果。

     
    图5-4  举重比赛与负载测试有相同之处

    通过负载测试方法,我们可以发现系统的处理极限点在哪里。

    负载测试的特点

    负载测试方法有如下几个特点。

    (1)它的主要目的在于找到系统处理能力的极限,为系统进一步优化做参考。另外,这种测试也可以用来比较不同的优化方法对于性能极限的提升,因此也可以称之为可扩展性测试(Scalability Testing)。这个名词可以用图5-5清晰地表述出来。

    在图5-5中,2条曲线分别代表两种优化方法经历负载测试的结果。A方法的性能极限在A点,B方法的性能极限在B点。根据负载测试的定义,比A、B两点值小的部分都是系统的安全运行区间。由于B的数值要大于A,说明采用B方法优化,系统的可扩展性提高了。

     
    图5-5  负载测试用于优化方法的比较:B好于A

    (2)负载测试方法的操作是一个不断加压的过程。负载测试方法是一个"性能指标记录--增加负荷"的操作循环,直到预定被关注的性能指标不再令人满意。这个极限点在测试结果中的表示类似这样的形式:"在给定条件下当前Web应用将最多允许10000个并发用户访问"、"在给定条件下当前Web应用最多能够在1分钟内处理1000次用户对数据库的修改"等。常见的在负载测试方法中被关注的性能指标包括:Web应用的响应时间、Web服务器平均CPU利用率等,它们的具体数值需要根据实际情况来调整。

    (3)负载测试方法要考虑被测Web应用的实际业务负荷量与正确的使用场景,以保证测试结果具有参考价值。

    【实战演练:教训】

    在这方面,笔者的同事曾经有一个教训。有一个网站,可以通过Web直接访问,也可以通过RSS进行订阅。在网站发布之前,网站技术部门的所有工程师都认为绝大部分用户都是通过Web来访问的,因此,在时间紧迫的情况下,重点测试了Web访问的性能,对于RSS相关代码测试的就很少。结果在网站上线之后,他们惊奇地发现,大部分用户访问都是通过RSS来完成的,因为负载测试做的很简略,结果每过多久服务器就被拖的几乎无法访问了。可见,对于负载测试,乃至整个性能测试而言,模拟真实的应用场景是多么的关键。

     

    原文: http://book.51cto.com/art/201008/218491.htm

    展开全文
  • 负载测试中极限负载 负载测试并非易事。 通常不仅要下载JMeter或Gatling ,记录一些方案然后运行它们。 好吧,也许就是这样,但是如果您是幸运的话。 听起来像“上尉的讲话”,但最好记住一些可能浪费时间的事情。 ...

    负载测试中极限负载

    负载测试并非易事。 通常不仅要下载JMeterGatling ,记录一些方案然后运行它们。 好吧,也许就是这样,但是如果您是幸运的话。 听起来像“上尉的讲话”,但最好记住一些可能浪费时间的事情。

    因此,当您运行测试时,最终您将遇到瓶颈,然后必须弄清楚它在哪里。 有可能:

    • 客户端瓶颈–如果您的负载测试工具使用HttpURLConnection,则客户端发送的请求数量非常有限 您必须从此开始,并确保有足够的请求离开负载测试机
    • 网络瓶颈–检查出站连接是否允许所需数量的请求到达服务器
    • 服务器计算机瓶颈–检查(很可能是)Linux服务器允许的打开文件数。 例如,如果默认值为1024,则最多可以有1024个并发连接。 因此增加(limits.conf)
    • 应用程序服务器瓶颈–如果处理请求的线程池太低,则请求可能会一直等待。 如果其他一些微小的配置开关(例如,是否应该使用NIO,这值得单独介绍)具有错误的值,则可能会降低性能。 您必须熟悉服务器性能相关的配置。
    • 数据库瓶颈–检查数据库的CPU使用率和响应时间,以查看是否不是导致请求减慢的原因。 数据库配置错误,或数据库服务器太小/很少,显然是瓶颈
    • 应用程序瓶颈–您可能必须使用一些性能监视工具来进行自我调查(但请谨慎选择,因为其中有许多“新颖而又酷”,但不稳定且无用的工具)。 我们可以将这种类型分为两种:
        框架瓶颈–如果您使用的框架有问题。

    您必须经常监视计算机的CPU,内存,网络和磁盘I / O使用情况,才能了解何时遇到硬件瓶颈。

    一个重要方面是能够以足够多的请求轰炸您的服务器。 单台机器不足的可能性不大,尤其是如果您是一家大公司,并且您的产品很可能在一开始就吸引大量客户和/或发出请求也需要一定的处理能力(例如,加密)。 因此,您可能需要一堆机器来运行负载测试。 您使用的工具可能不支持该工具,因此您可能必须手动协调群集。

    作为负载测试的结果,您必须考虑让连接等待多长时间以及何时拒绝连接。 这由客户端上的连接超时和服务器上的注册超时(或池借用超时)控制。 查看结果时也要记住这一点-响应太慢或连接被拒绝实际上是同一回事-您的服务器无法处理请求。

    如果您使用的是AWS,则有一些细节。 将自动缩放比例分开(可能应该至少在某些运行中将其禁用),您需要记住ELB需要预热。 多次运行测试以预热ELB(许多请求在失败之前将失败)。 另外,当使用负载平衡器并且长期连接处于打开状态(例如,您使用WebSocket)时,负载平衡器可能会将其自身与位于其后的服务器的连接永远保持打开状态,并在新请求时重新使用它们。持久的连接来了。

    总体而言,负载(性能)测试和分析并不简单,存在许多可能的问题,但这是发布之前必须要做的事情。 好吧,除非您预计用户不会超过100。 下一次,我将使用自己的文章作为参考,以确保我不会丢失任何东西。

    翻译自: https://www.javacodegeeks.com/2014/09/load-testing-guidelines.html

    负载测试中极限负载

    展开全文
  • 负载测试是为一个应用或系统尽可能地接近成品部署并在用户群中创建的模拟环境。一个负载测试可以测量响应时间,吞吐率和资源利用率,并确定应用程序的性能瓶颈,假设性能瓶颈的出现低于负载峰值。 在这里,“低于...

    负载测试是为一个应用或系统尽可能地接近成品部署并在用户群中创建的模拟环境。一个负载测试可以测量响应时间,吞吐率和资源利用率,并确定应用程序的性能瓶颈,假设性能瓶颈的出现低于负载峰值。
    在这里,“低于负载峰值”再次简单地表明,负载测试的参数落在压力测试(根据定义,指测试系统在或超出最大负载时的运行状况)范围内。负载测试可以发现系统延时,页面加载问题,以及当多个用户访问一个应用程序或高并发致使系统崩溃,这类问题在开发和测试环境中容易被忽视即便代码已经检查了很多遍。成百上千人同时访问软件时,一些探测不到的问题可能会突然出现。
    负载测试
    举例来说,假设你正在开发一个新的在线投票平台,并且希望它在负载高峰时段能承受每分钟10,000次用户提交请求。在开发软件时,写代码阶段你可能就执行了单元测试,周期性回归测试,以确保在新功能开发进程中没有破坏已有的功能。但你在什么时候开始做大规模用户测试?什么时候你开始测试程序接受成百上千的重叠字段项,表单提交和其他命令?
    从技术角度讲,在一个项目生产的末期,才会进行有真实用户参与的能够精确模拟系统性能的负载测试。这与汽车生产类似:你可以修复和测试引擎,但如果引擎没有安装,则不能测试汽车在道路上的表现。其实,在软件开发项目中的早期,你就能以一个集中的方式来测试特定组件的负载,例如测试后端性能问题,同时用户输入,在延长的时间周期里输入的耐力,或其他任何可以给系统施压,造成延时,内存泄漏或功能崩溃的方式。那就意味着你已经进行了负载测试,只不过是以一种受限的形式,并且已经在探索多用户访问对系统的影响了。在一个不完整的系统上进行少数用户输入测试,正确的负载测试需要一个几乎完整的系统,并且通常要求使用可以真实模拟数千用户的测试工具。
    但有一个对所有规则的例外。对互联网应用而言有一个很明确的多用户问题,负载测试可以在系统上进行,而不必通过众多用户,因为多个用户不是负载的唯一可能来源。有时负载可能是由大文件,大量的计算,甚至是弱网连接造成的。
    负载测试工具和性能测试工具的最终目的一般总是为了降低风险,无论是对于软件成功功能的风险,最终用户感知的风险,或对公司底线的风险。当然,所有这三个是紧密交织在一起,所以,对于一个开发人员或测试人员知道它们是如何相互关联的是很重要的。要敢于提出建议,如果你专注于减少中间标准,那么用户感知和其他两个因素通常会水到渠成。许多负载测试的问题归根结底,更多的在于用户感知,而非具体理想的页面加载时间和其他技术统计数据。
    换句话说,如果你不理解人类的心理、用户的行为和反应,你就不可能实现一个很真实的负载测试,并且更糟的是,你可能会误解测试结果。这就是为什么在执行负载测试时尽可能地模拟真实的终端用户体验很重要的原因,重复模拟用户在接近最大负载时访问一个网站或应用程序,分析测试结果,然后对系统进行相应的,尽最大可能来减少用户体验中的不愉快因素。由于开发周期越来越短,软件公司可以通过简单地专注于特定的故障以使用户体验更平稳和高效,而不是解决高负载情况下遇到的所有问题,这样可以节省时间和金钱。

    展开全文
  • 负载测试压力测试区别 The irony is that simultaneously with the launch of the test, we reached the limits on the production server, resulting in two-hour service downtime. This further encouraged us ...

    负载测试压力测试区别

    The irony is that simultaneously with the launch of the test, we reached the limits on the production server, resulting in two-hour service downtime. This further encouraged us to move from making occasional tests to establishing an effective load testing infrastructure. By infrastructure, I mean all tools for working with load testing: tools for launching the test (manual and automatic), the cluster that creates the load, a production-like cluster, metrics and reporting services, scaling services, and the code to manage it all.

    具有讽刺意味的是,在测试启动的同时,我们达到了生产服务器的极限,导致两个小时的服务停机时间。 这进一步鼓励我们从偶尔进行测试过渡到建立有效的负载测试基础结构。 对于基础架构,我指的是用于进行负载测试的所有工具:用于启动测试的工具(手动和自动),创建负载的集群,类似于生产的集群,指标和报告服务,扩展服务以及用于管理的代码这一切。

    image

    Simplified, this is what our structure looks like: a collection of different servers that somehow interact with each other, each server performing specific tasks. It seemed that to build the load testing infrastructure, it was enough for us to make this diagram, take account of all interactions, and start creating test cases for each block one by one.

    简化后,这就是我们的结构:一组以某种方式相互交互的不同服务器的集合,每个服务器执行特定的任务。 看起来,构建负载测试基础结构足以让我们制作此图,考虑所有交互并开始为每个模块逐个创建测试用例。

    This approach is right, but it would have taken many months, which was not suitable for us because of our rapid growth — over the past twelve months,

    这种方法是正确的,但是要花很多个月的时间,由于我们的快速发展,它不适合我们-在过去的12个月中,

    我们的在线活跃用户从12,000个增加到100,000个 (we have grown from 12,000 to 100,000 simultaneously active online users)

    . Also, we didn’t know how our service infrastructure would respond to the increased load: which blocks would become the bottleneck, and which would scale linearly?

    。 此外,我们也不知道我们的服务基础架构将如何应对不断增加的负载:哪些块将成为瓶颈,哪些块将线性扩展?

    In the end, we decided to test the service with virtual users simulating real activity — that is, to build a clone of the production environment and make a big test that will:

    最后,我们决定使用模拟真实活动的虚拟用户来测试服务,即构建生产环境的克隆并进行一个大型测试,该测试将:

    • create a load on a cluster that is structurally identical to the production cluster but which surpasses it in terms of performance;

      在结构上与生产集群相同但在性能方面超过它的集群上创建负载;
    • give us all the data for making decisions;

      向我们提供决策所需的所有数据;
    • show that the entire infrastructure is capable of withstanding the necessary load;

      证明整个基础架构能够承受必要的负载;
    • become the basis for load tests that we may need in the future.

      成为我们将来可能需要的负载测试的基础。
    • The only disadvantage of such a test is its cost because it will require an environment more extensive than the production environment.

      这种测试的唯一缺点是它的成本,因为它将需要比生产环境更广泛的环境。

    In this article, I will talk about creating a realistic test scenario, plugins (WS, Stress-client, Taurus), a load-generating cluster, and a production cluster, and I will show examples of using tests. In the next article, I will describe how we manage hundreds of load-generating servers.

    在本文中,我将讨论创建实际的测试方案,插件(WS,Stress-client,Taurus),负载生成集群和生产集群,并展示使用测试的示例。 在下一篇文章中,我将描述我们如何管理数百个负载生成服务器。

    创建现实的测试方案 (Creating a realistic test scenario)

    To create a realistic test scenario, we need to:

    要创建现实的测试方案,我们需要:

    • analyze users’ activity in the production environment, and to do this, identify essential metrics, start collecting them, and analyze the peaks;

      分析用户在生产环境中的活动,并为此确定基本指标,开始收集指标并分析峰值;
    • create convenient, customizable blocks that we can use to effectively create a load on the right part of the business logic;

      创建方便的,可定制的块,我们可以用来在业务逻辑的正确部分上有效地创建负载;
    • verify the realism of the test scenario by using server metrics.

      通过使用服务器指标来验证测试方案的真实性。

    Now, more details about each item.

    现在,有关每个项目的更多详细信息。

    分析生产环境中的用户活动 (Analyzing users’ activity in the production environment)

    In our service, users can create whiteboards and work on them with different content: photos, texts, mockups, stickers, diagrams, etc. The first metric we need to collect is the number of whiteboards and the distribution of content on them.

    在我们的服务中,用户可以创建白板并在其上处理不同的内容:照片,文本,模型,贴纸,图表等。我们需要收集的第一个指标是白板的数量及其上内容的分布。

    image

    On the same whiteboard at the same time, some users can be actively doing something — creating, editing, deleting the content — and some can simply be viewing the content. The ratio of users changing the content on the whiteboard to the total number of users of that whiteboard is also an important metric. We can derive this data from database usage statistics.

    同时在同一白板上,一些用户可以积极地做某事-创建,编辑,删除内容-有些则可以简单地查看内容。 更改白板内容的用户与该白板用户总数的比率也是一项重要指标。 我们可以从数据库使用情况统计信息中得出此数据。

    In our backend, we use a component approach. We call the components “models.” We break our code into models so that each model is responsible for a specific part of the business logic. We can count the number of database calls that occur through each model and identify the part of the logic that creates the heaviest load.

    在后端,我们使用组件方法。 我们称这些组件为“模型”。 我们将代码分成模型,以便每个模型负责业务逻辑的特定部分。 我们可以计算通过每个模型发生的数据库调用的数量,并确定造成最大负载的逻辑部分。

    image

    方便的,可定制的块 (Convenient, customizable blocks)

    For example, we need to add a block to the test scenario that will create a load on our service identical to the load that happens when you open a dashboard page with a list of user whiteboards. When this page loads, HTTP requests containing a large amount of data are sent: the number of whiteboards, accounts to which the user has access, all users of the account, and so on.

    例如,我们需要在测试场景中添加一个块,以在我们的服务上创建负载,该负载与您打开包含用户白板列表的仪表盘页面时发生的负载相同。 加载此页面时,将发送包含大量数据的HTTP请求:白板数,用户有权访问的帐户,该帐户的所有用户,等等。

    image

    How to create an efficient load on a dashboard? When analyzing the behavior of the production environment, we saw database usage spikes during the opening of the dashboard of a large account. We can create an identical account and change the intensity of its data usage in the test case, effectively loading the dashboard with a small number of calls. We can also create an uneven load for better realism.

    如何在仪表板上创建有效负载? 在分析生产环境的行为时,我们看到在打开大型帐户的仪表板期间数据库使用量激增。 我们可以创建一个相同的帐户,并在测试用例中更改其数据使用强度,从而以少量的呼叫有效地加载仪表板。 我们还可以创建不均匀的负载以获得更好的真实感。

    At the same time, it is crucial for us that the number of virtual users and the load generated by them are as similar as possible to the users and the load in the production environment. For this, we also recreate the background load on an average dashboard in the test. Thus, most virtual users work on small average dashboards, and only a few users create a destructive load, as happens in the production environment.

    同时,对我们而言至关重要的是,虚拟用户的数量和虚拟用户所产生的负载应尽可能类似于生产环境中的用户和负载。 为此,我们还要在测试中的平均仪表板上重新创建后台负载。 因此,大多数虚拟用户都在较小的平均仪表板上工作,而只有少数用户会像生产环境中那样产生破坏性的负载。

    From the start, we did not want to cover each server role and each interaction with a different test case. This can be seen in the dashboard example — during the test, we simply repeat what happens when a user opens a dashboard in the production environment. We do not cover what it affects with synthetic test cases. This allows us to cover nuances that we didn’t even expect with the test by default. Thus, we approach the creation of an infrastructure test from the side of business logic.

    从一开始,我们就不想用不同的测试用例介绍每个服务器角色和每个交互。 这可以在仪表板示例中看到–在测试期间,我们仅重复用户在生产环境中打开仪表板时发生的情况。 我们不涵盖它对综合测试用例的影响。 默认情况下,这使我们能够涵盖我们什至没有想到的细微差别。 因此,我们从业务逻辑的角度着手创建基础结构测试。

    This is the logic we used to efficiently load all other blocks of the service. At the same time, each block may not be realistic from functional logic; the important part is that it provides a realistic load according to server metrics. Then, using these blocks, we can create a test scenario that simulates real users’ activity.

    这是我们用来有效加载服务的所有其他块的逻辑。 同时,从功能逻辑上讲,每个方框可能都不现实。 重要的部分是它根据服务器指标提供了实际的负载。 然后,使用这些模块,我们可以创建一个模拟真实用户活动的测试场景。

    数据是测试用例的一部分 (Data is part of the test case)

    It is important to keep in mind that data is also part of the test case, and the code logic itself heavily depends on it. When building an extensive database for the test — and it obviously should be large for a large infrastructure test — we need to learn how to create data that will not distort the test during the execution. If we put bad data into the database, the test scenario can become unrealistic, and in an extensive database, that would be hard to fix. Therefore, we started creating data in the same way our users do use the REST API.

    重要的是要记住,数据也是测试用例的一部分,而代码逻辑本身就严重依赖它。 在为测试构建一个广泛的数据库时-对于大型基础架构测试来说显然它应该很大-我们需要学习如何创建在执行过程中不会扭曲测试的数据。 如果我们将不良数据放入数据库中,则测试场景可能变得不切实际,并且在庞大的数据库中,这将很难修复。 因此,我们开始以与用户使用REST API相同的方式创建数据。

    For example, to create whiteboards with existing data, we make API requests that load the whiteboard from the backup. As a result, we get genuine real data — different whiteboards of different sizes. At the same time, the database is being filled relatively quickly because our script is making requests in multiple threads. In terms of speed, this is comparable to the generation of garbage data.

    例如,要使用现有数据创建白板,我们发出API请求以从备份加载白板。 结果,我们获得了真实的真实数据-不同大小的不同白板。 同时,由于我们的脚本在多个线程中发出请求,因此数据库的填充速度相对较快。 在速度方面,这可与垃圾数据的生成相媲美。

    本部分小结 (Summary of this part)

    • Use realistic cases if you want to test everything at once;

      如果要一次测试所有内容,请使用实际案例;
    • Analyze real user behavior to design the structure of the test cases;

      分析实际用户行为以设计测试用例的结构;
    • From the very start, create convenient blocks to customize the testing process;

      从一开始就创建方便的块以自定义测试过程;
    • Configure the tests according to the real server metrics, not the usage analytics;

      根据真实服务器指标(而非使用情况分析)配置测试;
    • Do not forget that data is part of the test case.

      不要忘记数据是测试用例的一部分。

    负载生成集群 (Load-generating cluster)

    image
    Our load-generating tooling我们的负载生成工具

    In JMeter, we create a test that we launch using Taurus to create a load on various servers: web, API, and board servers. We perform database tests separately using PostgreSQL, not JMeter, so the diagram shows a dashed line.

    在JMeter中,我们创建一个测试,然后使用Taurus启动测试,以在各种服务器(Web,API和板服务器)上创建负载。 我们使用PostgreSQL而不是JMeter分别执行数据库测试,因此该图显示了虚线。

    WebSocket内部的自定义工作 (Custom work inside a WebSocket)

    Work on the whiteboard takes place inside a WebSocket connection, and it is on the whiteboard that multiuser work is possible. Nowadays, JMeter Plugins Manager has several plugins for working with WebSocket connections. The logic is the same everywhere — the plugin simply opens a WebSocket connection, and every action that occurs inside it, in any case, you have to write yourself. Why is that? Because it is impossible to work with WebSocket connections similarly to HTTP requests, that is, we cannot create a test case, extract dynamic values, and pass them along.

    白板上的工作在WebSocket连接内部进行,并且可以在白板上进行多用户工作。 如今,JMeter插件管理器有几个用于处理WebSocket连接的插件。 逻辑无处不在-插件只是打开一个WebSocket连接,在其中发生的每个动作(无论如何)都必须自己编写。 这是为什么? 因为不可能像HTTP请求那样使用WebSocket连接,也就是说,我们无法创建测试用例,提取动态值并传递它们。

    The work inside a WebSocket connection is usually very customized: you invoke specific custom methods passing specific custom data, and therefore, you need your means of understanding whether the request was executed correctly and how long it took to execute. You also have to write the Listeners inside that plugin yourself — we haven’t found an excellent ready-made solution.

    WebSocket连接中的工作通常是高度定制的:您调用传递特定定制数据的特定定制方法,因此,您需要了解是否正确执行请求以及执行该请求需要花费多长时间的方法。 您还必须自己在该插件中编写侦听器-我们还没有找到一个很好的现成解决方案。

    压力客户 (Stress-client)

    We want to make it as easy as possible to replicate what real users do. But we do not yet know how to record and replay everything that is happening in WebSocket inside the browser. If we recreate everything inside WebSocket from scratch, then we would get a new client, not the one that is used by real users. There is no incentive to write a new client if we already have one working.

    我们希望尽可能简单地复制真实用户的行为。 但是我们还不知道如何记录和重播浏览器内部WebSocket中发生的一切。 如果我们从头开始在WebSocket中重新创建所有内容,那么我们将获得一个新的客户端,而不是实际用户使用的客户端。 如果我们已经有一位新客户,则没有动力去写一位新客户。

    So we decided to put our client inside JMeter. And we faced several difficulties. For example, JavaScript execution inside JMeter is a whole other topic, because it uses a very specific version of the language. And if you want to use your existing client code, you probably won’t be able to do that, because modern JavaScript features are not supported, and you’ll have to rewrite parts of your code.

    因此,我们决定将客户放入JMeter。 而且我们面临一些困难。 例如,JMeter内部JavaScript执行是另一个主题,因为它使用了非常特定的语言版本 。 而且,如果您想使用现有的客户端代码,则可能将无法执行此操作,因为不支持现代JavaScript功能,并且您将不得不重写部分代码。

    The second difficulty is that we don’t want to support the entire client code for load tests. Therefore, we removed everything from the client but the client-server interaction. This allowed us to use client-server methods and do everything that our client can do. The advantage of this is that client-server interaction very rarely changes, which means that the code support inside the test case is seldom required. For instance, over the last six months, I haven’t made any changes to the code because it works perfectly.

    第二个困难是我们不想为负载测试支持整个客户端代码。 因此,我们从客户端中删除了所有内容,但没有删除客户端与服务器之间的交互。 这使我们能够使用客户端-服务器方法并执行客户端可以做的所有事情。 这样做的好处是客户端与服务器之间的交互很少更改,这意味着几乎不需要测试用例中的代码支持。 例如,在过去的六个月中,我没有对代码进行任何更改,因为它可以完美运行。

    The third difficulty is that the introduction of large scripts significantly complicates the test case. First, it can become a bottleneck in the test. Second, we most likely will not be able to run a large number of threads from one machine. Right now, we are only able to run 730 threads.

    第三个困难是大脚本的引入使测试案例大大复杂化。 首先,它可能成为测试的瓶颈。 其次,我们很可能将无法在一台计算机上运行大量线程。 目前,我们只能运行730个线程。

    我们在亚马逊实例上的例子 (Our example at the Amazon instance)

    JMeter server type in AWS: m5.large ($0.06 per hour)
    vCPU: 2
    Mem (GiB): 8
    Dedicated EBS Bandwidth (Mbps): Up to 3,500
    Network Performance (Gbps): Up to 10
    → ~730 threads

    在哪里获得数百台服务器以及如何省钱 (Where to get hundreds of servers and how to save money)

    Next, the question arises: 730 threads from one machine, but we want 50,000 — where can we get so many servers? We are creating a cloud-based solution, so buying servers to test a cloud solution seems odd. Plus, there is always a certain slowness in buying new hardware. Therefore, we need to deploy them in the cloud as well, so we ended up choosing between cloud providers and cloud-based load testing tools.

    接下来,问题来了:一台机器上有730个线程,但我们需要50,000个线程-在哪里可以得到这么多服务器? 我们正在创建一个基于云的解决方案,因此购买服务器以测试云解决方案似乎很奇怪。 另外,购买新硬件总是有一定的缓慢。 因此,我们也需要将它们部署在云中,因此我们最终在云提供商和基于云的负载测试工具之间进行选择。

    We decided not to use cloud-based load testing tools like Blazemeter and RedLine13 because their usage restrictions did not suit us. We have different test sites, so we wanted to find a universal solution that would allow us to reuse 90 percent of the work in local testing as well.

    我们决定不使用Blazemeter和RedLine13等基于云的负载测试工具,因为它们的使用限制不适合我们。 我们有不同的测试站点,因此我们想找到一个通用解决方案,该解决方案将使我们也可以在本地测试中重复使用90%的工作。

    Hence, in the end, we were choosing between cloud service providers.

    因此,最后,我们在云服务提供商之间进行选择。

    Our platform is AWS-based, and almost all testing is done there, so we want the test bench to be as similar as possible to the production environment. Amazon has a lot of paid features, some of which, like load balancers, we use in production. If you don’t need these features in AWS, you can get them 17 times cheaper in Hetzner. Or you can get servers at Hetzner, use OpenStack, and write the balancers and other features yourself since with OpenStack, you can replicate the entire infrastructure. We managed to do just that.

    我们的平台基于AWS,并且几乎所有测试都在此完成,因此我们希望测试平台与生产环境尽可能相似。 亚马逊有很多付费功能,其中一些功能,例如我们在生产中使用的负载均衡器。 如果您在AWS中不需要这些功能,则可以在Hetzner中将它们便宜17倍。 或者,您可以在Hetzner上获得服务器,使用OpenStack并自己编写平衡器和其他功能,因为使用OpenStack,您可以复制整个基础架构。 我们设法做到了。

    Testing of 50,000 users using 69 AWS instances costs us about $3,000 per month. How do we save money? One way is to use temporary AWS instances — Spot instances. Their main benefit is that instead of keeping instances running all the time, we only launch them for tests, and they cost much less. One important detail, however, is that somebody can outbid your offer right at the time of testing. Fortunately, this has never happened to us, and we already save at least 60 percent of the cost thanks to them.

    使用69个AWS实例对50,000个用户进行测试,每月费用约为3,000美元。 我们如何省钱? 一种方法是使用临时AWS实例-Spot实例。 它们的主要好处是,我们不必使实例一直保持运行状态,而是仅将它们启动进行测试,并且成本更低。 但是,一个重要的细节是,有人可以在测试时出价超出您的报价。 幸运的是,这从未发生过,而且由于他们,我们已经节省了至少60%的成本。

    负载生成集群 (Load-generating cluster)

    We use the default JMeter cluster. It works perfectly; it does not have to be modified in any way. It has several launch options. We use the simplest option, where one master launches N number of instances, and there can be hundreds of them.

    我们使用默认的JMeter集群。 它运作完美; 不必进行任何修改。 它有几个启动选项。 我们使用最简单的选项,其中一个主服务器启动N个实例,并且可以有数百个实例。

    image

    The master runs a test scenario on the JMeter servers, keeps communicating with them, collects general statistics from all instances in real-time, and displays it in the console. Everything looks the same as running the test scenario on a single server, even though we see the results of running it on a hundred servers.

    主机在JMeter服务器上运行测试方案,保持与它们的通信,实时从所有实例收集常规统计信息,并将其显示在控制台中。 尽管我们看到在一百台服务器上运行测试方案的结果,但一切看起来都与在一台服务器上运行测试方案相同。

    For a detailed analysis of the results of test scenario execution in all instances, we use Kibana. We parse the logs with Filebeat.

    为了对所有情况下的测试方案执行结果进行详细分析,我们使用Kibana。 我们使用Filebeat解析日志。

    image

    适用于Apache JMeter的Prometheus侦听器 (Prometheus Listener for Apache JMeter)

    JMeter has a plugin for working with Prometheus, which out of the box provides all JVM and thread usage statistics inside the test. This allows you to see how often users log in, log out, and so on. The plugin can be customized to send the test scenario run data to Prometheus and display it in real-time in Grafana.

    JMeter有一个用于Prometheus插件,插件开箱即用地提供了测试中的所有JVM和线程使用情况统计信息。 这使您可以查看用户登录,注销等的频率。 可以对插件进行自定义,以将测试方案运行数据发送到Prometheus并在Grafana中实时显示。

    image

    金牛座 (Taurus)

    We want to solve some current problems with Taurus, but we haven’t started that yet:

    我们想解决金牛座的一些当前问题,但我们还没有开始:

    • Configurations instead of test scenario clones. If you have worked with JMeter, you have probably faced the need to run test scenarios with different sets of source parameters, for which you had to create clones of the test scenarios. In Taurus, you can have one test scenario and manage its launch parameters using configurations;

      配置而不是测试方案克隆。 如果您使用过JMeter,则可能已经遇到了需要使用不同的源参数集运行测试方案的情况,为此您必须创建测试方案的克隆。 在Taurus中,您可以使用一种测试方案并使用配置来管理其启动参数。
    • Configs for controlling JMeter servers when working with a cluster;

      使用集群时用于控制JMeter服务器的配置;
    • An online results analyzer that allows you to collect the results separately from the JMeter threads and not to complicate the test scenario itself;

      一个在线结果分析器,它使您可以从JMeter线程中单独收集结果,而不会使测试场景本身复杂化;
    • Easy integration with CI;

      易于与CI集成;
    • Capability to test a distributed system.

      测试分布式系统的能力。

    本部分小结 (Summary of this part)

    • If we use custom code inside JMeter, it is better to think about its performance right away, because otherwise, we will end up testing JMeter and not our product;

      如果我们在JMeter中使用自定义代码,最好立即考虑其性能,因为否则,我们将最终测试JMeter,而不是我们的产品;
    • The JMeter cluster is a beautiful thing: it is easy to set up, and it’s easy to add monitoring to;

      JMeter集群是一件很漂亮的事情:它易于设置,并且易于添加监视。
    • A large cluster can be maintained on AWS Spot instances; it will be much cheaper;

      可以在AWS Spot实例上维护大型集群; 它会便宜得多;
    • Be careful with Listeners in JMeter so that the test scenario does not slow down with a large number of servers.

      在JMeter中使用侦听器时要小心,以免在使用大量服务器的情况下降低测试速度。

    使用基础架构测试的示例 (Examples of using infrastructure tests)

    The whole story above is largely about creating a realistic case to test the limits of the service. The examples below show how you can reuse the work you have done on the load testing infrastructure to solve local problems. I will talk in detail about two out of about ten types of load tests that we conduct periodically.

    上面的整个故事主要是关于创建一个实际案例来测试服务的限制。 以下示例显示了如何重用在负载测试基础结构上完成的工作来解决本地问题。 我将详细讨论我们定期进行的大约十种类型的负载测试中的两种。

    数据库测试 (Database testing)

    What can we load test in the database? Big queries are an unlikely target because we can test them in a single-threaded mode if we just look at the query plans.

    我们可以在数据库中加载什么测试? 大查询是不太可能的目标,因为如果我们仅查看查询计划,就可以在单线程模式下对其进行测试。

    More interesting is the situation where we run the test and see the load on the disk. The graph shows an increase in iowait.

    更有趣的是,我们运行测试并查看磁盘上的负载。 该图显示了iowait的增加。

    image

    Next, we see that this affects users.

    接下来,我们看到这会影响用户。

    image

    Then we understand the reason: VACUUM did not run and did not remove the garbage data from the database. If you’re not familiar with PostgreSQL, VACUUM is similar to Garbage Collector in Java.

    然后我们了解原因:VACUUM没有运行,也没有从数据库中删除垃圾数据。 如果您不熟悉PostgreSQL,VACUUM类似于Java中的Garbage Collector。

    image

    The next thing we see is that CHECKPOINT started to trigger out of schedule. For us, this is a signal that the PostgreSQL configs do not adequately match the intensity of the database usage.

    我们接下来看到的是CHECKPOINT开始触发超出计划的时间。 对我们来说,这表明PostgreSQL配置与数据库使用强度不完全匹配。

    image

    Our task is to adjust the database configuration so that such situations do not happen again. PostgreSQL, for instance, has many settings. For fine-tuning, you need work in short iterations: change the settings, launch the server, evaluate, repeat. For that, of course, you need to provide a good load on the database, and this requires extensive infrastructure tests.

    我们的任务是调整数据库配置,以免再次发生这种情况。 例如,PostgreSQL有许多设置。 为了进行微调,您需要进行短暂的迭代:更改设置,启动服务器,评估,重复。 为此,当然,您需要在数据库上提供良好的负载,这需要大量的基础架构测试。

    One thing is that for the test to carry on normally without any unnecessary crashes, it must take a long time. In our case, the test takes about three hours, which no longer looks like a short iteration.

    一件事是,要使测试正常进行而没有任何不必要的崩溃,它必须花费很长时间。 在我们的例子中,测试大约需要三个小时,这看起来不再像是短暂的迭代。

    We look for a solution. We find a tool for PostgreSQL called pgreplay. It can reproduce — using multiple threads — exactly what is written in log files, exactly the way it happened at the time of writing. How can we use it effectively? We make a dump of the database, then log everything that happens to the database after the dump, and then we can deploy the dump and replay everything that happened to the database using multiple threads.

    我们正在寻找解决方案。 我们为PostgreSQL找到了一个名为pgreplay的工具。 它可以使用多个线程来复制日志文件中所写的内容,以及在编写时发生的方式。 我们如何有效地使用它? 我们对数据库进行转储,然后记录转储后数据库中发生的所有事情,然后我们可以部署转储并使用多个线程重播数据库中发生的所有事情。

    Where to write logs? A popular solution for logging is to collect logs in the production environment, as this gives the most realistic and reproducible test case. But there are some problems with that:

    在哪里写日志? 一种流行的日志记录解决方案是在生产环境中收集日志,因为这提供了最现实和可重复的测试用例。 但这有一些问题:

    • You have to use production data for testing, which is not always possible;

      您必须使用生产数据进行测试,但这并不总是可能的。
    • This process uses the syslog feature, which is expensive;

      此过程使用syslog功能,这很昂贵;
    • Disk usage is increased.

      磁盘使用率增加。

    Our approach to large-scale testing helps us here. We make a database dump on the test environment, run a sizeable realistic test, and log everything that happens during the execution of that test. Then we use our tool called Marucy to run the database test:

    我们的大规模测试方法在这里为我们提供了帮助。 我们在测试环境上进行数据库转储,运行大型现实测试,并记录执行该测试期间发生的所有事情。 然后,我们使用名为Marucy的工具来运行数据库测试:

    1. An AWS instance is created;

      创建一个AWS实例;
    2. The dump we need is deployed;

      我们需要的转储已部署;
    3. pgreplay is launched to replay the logs that we need;

      启动pgreplay以重播我们需要的日志;
    4. We use our Prometheus/Grafana monitoring to evaluate the results. There are also dashboard examples in the repository.

      我们使用Prometheus / Grafana监视来评估结果。 存储库中还有仪表板示例。

    When launching Marucy, we can pass a few parameters that can change, for example, the intensity of the test.

    启动Marucy时,我们可以传递一些可以更改的参数,例如,测试强度。

    In the end, we use our realistic test scenario to create a database test, and then run this test without using a large cluster. It is important to note that to test any SQL database, the test case must be uneven, otherwise, the database will behave differently than it will in the production environment.

    最后,我们使用实际的测试场景来创建数据库测试,然后在不使用大型群集的情况下运行该测试。 重要的是要注意,要测试任何SQL数据库,测试用例必须是不均匀的,否则,数据库的行为将与生产环境中的行为不同。

    降解监测 (Degradation monitoring)

    For degradation tests, we use our realistic test scenario. The idea is that we need to ensure that the service has not become slower after another release. If our developers change something in the code that leads to increased response times, we can compare the new values with the reference values and signal if there is an error in the build. For the reference values, we use the current values that suit us.

    对于降级测试,我们使用实际的测试方案。 我们的想法是,我们需要确保该服务在另一个版本之后不会降低速度。 如果我们的开发人员更改了代码,从而导致响应时间增加,我们可以将新值与参考值进行比较,并在构建中出现错误时发出信号。 对于参考值,我们使用适合我们的当前值。

    Controlling the response times is useful, but we went further. We wanted to check that the response times during real users’ activity have not increased after the release. We thought that we could probably test something manually during the load testing, but that would only be dozens of cases. It’s more efficient to run the existing functional tests and check a thousand cases at the same time.

    控制响应时间很有用,但我们走得更远。 我们希望检查发布后实际用户活动期间的响应时间是否没有增加。 我们认为我们可以在负载测试期间手动测试某些东西,但是那只会是几十种情况。 运行现有的功能测试并同时检查一千个案例,效率更高。

    How did we set it up? There is a master that gets deployed to the test bench after the build. Then, the functional tests are automatically run in parallel with the load tests. After that, we get a report in Allure on how the functional tests performed under load.

    我们是如何设置的? 在构建之后,会有一个主服务器部署到测试台。 然后,功能测试会与负载测试同时自动运行。 之后,我们在《魅力》中获得了一份报告,介绍了功能测试如何在负载下执行。

    In this report, for example, we see that the comparison with the reference value has failed.

    例如,在此报告中,我们发现与参考值的比较失败。

    image

    We can also measure browser performance with functional tests. Or, a functional test will simply fail due to an increase in operation execution time under load, because a timeout on the client-side will be triggered.

    我们还可以通过功能测试来衡量浏览器的性能。 否则,功能测试将仅由于负载下操作执行时间的增加而失败,因为将触发客户端超时。

    本部分小结 (Summary of this part)

    • A realistic test allows you to test the database cheaply and easily configure it;

      现实的测试可以让您廉价地测试数据库,并轻松地对其进行配置。
    • Functional testing under load is possible.

      可以在负载下进行功能测试。

    P.S.: This article was first published on Medium.

    PS:本文最初发表于Medium

    翻译自: https://habr.com/en/company/miro/blog/499782/

    负载测试压力测试区别

    展开全文
  • 负载测试、压力测试

    2019-03-04 16:23:53
    负载测试 负载测试是模拟实际软件系统所承受的负载条件的系统负荷,通过不断加载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等,以...
  • 负载测试(Load testing)、压力测试(Stress Test,应称为强度测试)和性能测试,这三个概念常常引起混淆,难以区分,从而造成不正确的理解和错误的使用。之前,也有不少讨论,比较有名的,应归为Grig G...
  • 一:负载测试,并发测试,压力测试区别 负载测试 1、定义: 负载测试是通过逐步增加系统负载,测试系统性能的变化,并最终确定在满足性能指标的情况下,系统所能承受的最大负载量的测试。 2、目的: 不把系统搞挂的...
  • 负载测试和压力测试

    2020-07-02 14:15:01
    压力测试 压力测试是在强负载(大数据量、大量并发用户...负载测试 模拟实际软件系统所承受的负载条件的系统负荷,通过不断加载(逐渐增加用户数量)或其他加载方式来观察不同负载下的系统的响应时间和吞吐数据量、系统
  • 为您提供Locust负载测试工具下载,Locust 是一个开源负载测试工具。使用 Python 代码定义用户行为,也可以仿真百万个用户。Locust 是非常简单易用,分布式,用户负载测试工具。Locust 主要为网站或者其他系统进行...
  • 1、负载测试负载测试是模拟实际软件系统所承受的负载条件的系统负荷,通过不断加载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等,以...
  • 为您提供Locust负载测试工具下载,Locust 是一个开源负载测试工具。使用 Python 代码定义用户行为,也可以仿真百万个用户。Locust 是非常简单易用,分布式,用户负载测试工具。Locust 主要为网站或者其他系统进行...
  • 为您提供Locust负载测试工具下载,Locust 是一个开源负载测试工具。使用 Python 代码定义用户行为,也可以仿真百万个用户。Locust 是非常简单易用,分布式,用户负载测试工具。Locust 主要为网站或者其他系统进行...
  • 性能测试(或称多用户并发性能测试)、负载测试、强度测试、容量测试是性能测试领域里的几个方面,但是概念很容易混淆。 负载测试和压力测试,都属于性能测试的子集。 性能测试,表示在一个给定的基准下,能执行的...
  • 性能测试,负载测试,压力测试有什么区别性能测试(或称多用户并发性能测试)、负载测试、强度测试、容量测试是性能测试领域里的几个方面,但是概念很容易混淆。下面将几个概念进行介绍。 性能测试(Performance ...
  • 压力测试和负载测试的区别

    万次阅读 2019-01-10 10:29:57
    负载测试 模拟实际软件系统所承受的负载条件的系统负荷,通过不断加载(如逐渐增加模拟用户的数量)或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源(如CPU、内存)等,以检验系统的...
  • 1、负载测试(Load Test):负载测试是一种性能测试,指数据在超负荷环境中运行,程序是否能够承担。 关注点:how much 2、压力测试(Stress Test): 压力测试(又叫强度测试)也是一种性能测试,它在系统资源特别...
  • 在做一些软件测试工作时,常常会被提及性能测试、负载测试、压力测试,这也是在软件测试方面最容易混淆的三个概念。之前和一个测试大牛聊天,他和我说常常面试一些测试人员会问一些这样的问题,大多人认为负载测试...
  • 负载测试工具

    2020-01-22 14:02:17
    以下内容包括开源软件和许可的负载测试工具,但是几乎所有许可的工具都具有免费试用版,因此用户可以在决定哪种工具最适合他们的需求之前亲身实践: 1.网络负载 适用于Web应用程序的组织范围的负载和性能测试工具...
  • LoadRunner的负载测试

    2020-09-11 14:40:32
    LoadRunner的负载测试流程 LoadRunner负载测试一般包括5个阶段:规划、脚本创建、场景定义、场景执行和结果分析。 计划负载测试:定义性能测试要求,例如并发用户数量、典型业务流程和要求的响应时间。 创建Vuser...
  • 目录性能测试负载测试压力测试举例 一直以来,都对性能测试中的负载测试和压力测试觉得很混淆,感觉2个概念很像,不知道区别在哪里。这次专门找了很多资料,总结如下: 负载测试Load test:在[不同负载]下,给系统...
  • 第7章 LoadRunner负载测试工具的运用 7.1 LoadRunner负载测试工具概述 7.2 LoadRunner 的测试过程 7.3制定负载测试计划 7.4 开发测试脚本 7.5 创建运行场景 7.6 分析以及监视场景 7.7 分析实时监视图表 7.8利用...
  • 性能测试 负载测试 压力测试 容量测试 压力测试、负载测试和容量测试都是性能测试中的内容。 压力测试:检查被测系统在恶劣环境下的表现,比如内存不足,CPU高负荷,网速慢,等等。在 这种情况下,被测系统往往...
  • 本期CPU多核负载测试的测试机为惠普战99 AMD版。惠普战99 AMD版CPU:AMD锐龙7 4800H规格:8C16T基础频率:2.9GHz最大睿频(单核):4.2GHzTDP:45W详细参数:AMD官网50轮Cinebench R15多核负载测试如下:50轮Cinebench...
  • LoadUI是负载测试中的一个新的开源范例,它允许用户创建具有拖放功能的测试,并实时更改测试。 除了HTTP服务,JMS和数据库之外,此基于Java的工具还可用于测试Web服务,例如SOAP和RESTful。 现在可以从...
  • 性能测试,又称为多用户并发性能测试,通过模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试,压力测试和负载测试都属于性能测试。 二、压力测试(Stress Test) 压力测试,又叫强度测试,...
  • 通常搜集所有和测试相关的所有性能,通常被不同人在不同场合使用,包括负载测试,强度测试,容量测试等 1.负载测试 在一定的软硬件环境上,通过不断的加大负载来确定在满足性能指标情况下所能够承受的最大用户数。...
  • 性能测试与负载测试、压力测试,希望能帮助大家更了解软件测试的相关内容

空空如也

1 2 3 4 5 ... 20
收藏数 17,278
精华内容 6,911
关键字:

负载测试