在性能测试中考虑时间和CPU使用率

什么是性能测试？ (What is Performance Testing?)

We all have experienced slowness while browsing through a particular online application. While it could generally be due to interruption in the internet services or the network, but it could also mean that the overall response time of the application is slow. In order to check the response and stability of a web application under varying loads, Performance testing comes into picture.

浏览特定的在线应用程序时，我们所有人都遇到了速度慢的问题。 虽然通常可能是由于Internet服务或网络的中断，但也可能意味着应用程序的总体响应时间很慢。 为了在变化的负载下检查Web应用程序的响应和稳定性，需要进行性能测试。

In other words, Performance testing is basically checking the speed of the application, the crash point of an application while continuously putting varied load.

换句话说，性能测试基本上是在检查应用程序的速度，应用程序的崩溃点，同时不断施加变化的负载。

Another aspect of Performance testing is to make sure resource utilization is under control. For example, a web application may take up to 100% CPU utilization if not optimized properly and this could result overall slowness in a customer’s system. Consequence — bad reputation and sales goal is not met. Proper Performance testing could omit this issue and hence this type of testing is required.

性能测试的另一个方面是确保资源利用处于受控状态。 例如，如果未适当优化，则Web应用程序可能占用100％的CPU利用率，这可能会导致客户系统的整体运行缓慢。 结果-不良的声誉和销售目标未实现。 适当的性能测试可以忽略此问题，因此需要进行这种类型的测试。

There are various types of Performance testing that can be planned and each has separate set of goals. In this article, we will focus more on a very common problem that a tester may face and without the proper solution, the performance testing may fail or it will not provide the desired result. With the below scenario I am trying to point out that to run Performance testing, one should consider the mandatory parameters, if one such parameter, Think Time is missed then it can lead to failure of Performance test.

可以计划各种类型的性能测试，每种类型都有单独的目标。 在本文中，我们将把重点更多地放在测试人员可能面临的非常普遍的问题上，如果没有适当的解决方案，性能测试可能会失败或无法提供预期的结果。 对于以下情况，我试图指出，要运行性能测试，应考虑强制性参数，如果错过了这样的参数(思考时间)，则可能导致性能测试失败。

CPU使用率-性能测试中的问题 (CPU Usage — Issue in Performance Testing)

The issue that I am talking about is related to CPU usage and it’s hitting to 100%. I noticed 100% CPU utilization in my performance script, using Visual Studio tool, in certain iteration. The page response time, the transaction time were all absurdly high and even the manual tests performed at the same time when the load was put, showed some notorious page response time. The worrisome part was definitely CPU usage standing at 100% and HHTP 429 error which indicates that too many requests have been sent in a given amount of time.

我正在谈论的问题与CPU使用率有关，并且达到100％。 我注意到在某些迭代中使用Visual Studio工具的性能脚本中有100％的CPU使用率。 页面响应时间，事务处理时间都非常高，甚至在加载时同时进行的手动测试也显示了一些臭名昭著的页面响应时间。 令人担忧的是，CPU使用率肯定为100％，并且出现HHTP 429错误，这表明在给定的时间内发送了太多请求。

After doing a bit of R&D, I got to know tweaking Think time can help in resolving the issue or I can say Think time stopped the issue from occurring.

在进行了一些研发之后，我知道调整“思考时间”可以帮助解决问题，或者可以说“思考时间”阻止了问题的发生。

Now let us look at what is Think Time in Performance Testing.

现在让我们看看什么是性能测试中的思考时间。

什么是性能测试中的思考时间，为什么要使用它 (What is Think Time in Performance Testing and why do we use it)

As the name suggests, Think time is the time taken to think. Now, when a real-time user performs any action in a web application, he or she takes some time to do activities such as reading the content, typing a user id, password, or may be inserting data in some form. The time gap between actions, say 5 secs, so 5 secs would be Think Time. So, Think time is the time taken by any user to think in between two consecutive actions.

顾名思义，思考时间就是思考所需的时间。 现在，当实时用户在Web应用程序中执行任何操作时，他或她会花费一些时间来进行一些活动，例如读取内容，键入用户ID，密码或以某种形式插入数据。 动作之间的时间间隔为5秒，因此5秒就是思考时间。 因此，思考时间是任何用户在两个连续动作之间进行思考所花费的时间。

To simulate the similar type of action a Performance tester includes the Think Time in each request in the script. This Think Time will create the delay in the test environment that a real-time user does while navigating through a web application.

为了模拟类似的动作，性能测试器在脚本的每个请求中都包括了思考时间。 “思考时间”将在实时环境中浏览Web应用程序时在测试环境中造成延迟。

思考时间与CPU使用率有何关系？ (How Think Time is related to CPU Usage?)

There is another reason to introduce Think Time in Performance test. Without Think Time when a Performance test is run, thousand of requests get bombarded to the server without any pause. This situation makes the CPU think that it is a threat and CPU becomes too busy to handle the threat and increases its capacity to 100%. As a result, the server may fail and overall page response time increases. Due to this the Performance tester will not achieve the desired result.

在性能测试中引入思考时间是另一个原因。 如果在运行性能测试时没有“思考时间”，则成千上万的请求将被轰击到服务器而不会暂停。 这种情况使CPU认为这是一种威胁，并且CPU变得太忙以致无法处理威胁并将其容量增加到100％。 结果，服务器可能会发生故障，并且总的页面响应时间会增加。 因此，性能测试器将无法获得理想的结果。

Adding Think Time in between requests will halt the virtual users for a defined period of time and the CPU will not consider the requests as threats. This will help servers to process the requests without confusing the CPU and emulate Production like result.

在两次请求之间添加思考时间将使虚拟用户停止定义的时间段，CPU不会将这些请求视为威胁。 这将帮助服务器处理请求，而不会混淆CPU并模拟类似于Production的结果。

That is how my issue with CPU usage got resolved by adding Think Time in between the requests. After adding Think Time of 10 secs in between requests (27 requests) of my scripts, the CPU usage reduced to 20–25% which was a mirror reflection of Production environment.

通过在请求之间添加思考时间，可以解决我的CPU使用率问题。 在我的脚本请求(27个请求)之间添加了10秒的思考时间后，CPU使用率降低到20–25％，这反映了生产环境。

Now let us see where and how do we add Think Time in Performance Test script

现在让我们看看在性能测试脚本中在何处以及如何添加思考时间

添加思考时间的位置 (Where Think Time is added)

Think Time is added in between two requests or transactions. For example, a real-time user logs in to Facebook, performs a Search and Logs out, so here are three transactions, so Think Time should be added two times in between the transactions:

在两个请求或事务之间添加思考时间。 例如，一个实时用户登录到Facebook，执行搜索并注销，因此这是三个事务，因此应在事务之间添加两次“思考时间”：

Log In to Facebook ->THINK TIME->Search in FB->THINK TIME->Log Out

登录Facebook-> 思考时间 ->在FB中搜索-> 思考时间 ->注销

思考时间如何计算 (How is Think Time calculated)

Think Time depends on the size of the content; generally it should be in between 1 secs to 10 secs. Think Time extends the session of a user on the server, so it should be noted that Think Time shouldn’t be too large as it can restrict the user from creating a new session on the server. It shouldn’t be too less too, as the concurrency of the users will be interrupted. Scripts without Think Time should not be considered as it would create the issue that we discussed above.

思考时间取决于内容的大小； 通常，它应该在1秒到10秒之间。 “思考时间”扩展了服务器上用户的会话，因此应注意“思考时间”不应太大，因为它会限制用户在服务器上创建新会话。 不应太少，因为用户的并发性将被中断。 不应考虑没有思考时间的脚本，因为它会产生我们上面讨论的问题。

Calculating Think Time can be a little confusing for any Performance tester as the parameters to calculate think time should be in equivalent units of measurement. Many online calculators are available over the internet but most of them are faulty and doesn’t provide accurate result. I feel it is better to do some trial runs and by changing Think Time based on the content of a particular page can help. For example, if the first transaction is Login page and next is an Article page, then obviously the Think Time should be higher as a real-time user will take few minutes time to read an article.

对于任何性能测试人员而言，计算思考时间可能会有些混乱，因为计算思考时间的参数应以等效的度量单位。 互联网上有很多在线计算器，但是其中大多数都是有缺陷的，不能提供准确的结果。 我认为最好进行一些试运行，并根据特定页面的内容更改“思考时间”会有所帮助。 例如，如果第一个事务是“登录”页面，下一个是“文章”页面，则显然“思考时间”应该更高，因为实时用户将花费几分钟的时间来阅读文章。

A little dry run with multiple Think Time can help in achieving the target result.

进行多次思考时间的空转可以帮助实现目标结果。

翻译自: https://medium.com/@sayantaniray87/think-time-and-cpu-usage-in-performance-testing-51fd0b738d95