LoadrunnerStudy_事务+检查点

Posted 2023-03-22

参考技术A 一、Loadrunner中事务

LR度量的是客户端发送请求到服务器响应处理并返回的时间，看上去和响应时间没有差异，我在之前也都是这样认为的，但实质上事务和响应时间之间还是存在着一定的细微差异。

实际事务时间包括以下四个部分

第一部分:Wasted time，脚本录制过程中，自动插入所花费的时间；脚本录制后，手工编码输入执行所花费的时间。

第二部分:函数自身所消耗的时间，包括lr_start_transaction和lr_end_transaction

第三部分:Think Time，用于模拟用户思考的时间lr_think_time()

第四部分:响应时间 = 网络+服务器处理时间

注:在事务的时间计算中，会自动排除第一和第二种，第三部分是人为设置或是录制形成，只要做一下减法也可以排除，所以真正事务要度量的时间是第四部分，响应时间。

添加事务的方式

1、当对录制的脚本不是特别的熟悉时，可以选择录制时在工具栏添加事务，这样系统会在自动生成的脚本中插入事务函数

2、如果对脚本较为熟悉，可以选择在录制结束后添加事务

3、纯手工编码添加事务命令

补充：lr_end_transaction函数的int status有四种状态（根据状态去判断事务的执行情况）

LR_AUTO:自动根据规则来判断状态

LR_PASS:系统做了正确的事务，并且记录事务所执行的时间（响应时间）

LR_FAIL:事务失败，没有达到脚本应该有的效果（后期统计中将被独立统计）

LR_STOP:事务被停止

二、 Loadrunner中检查点

如何快速的知道一个脚本在回放时候是正确还是错误，在这里我们就要用到一个函数web_reg_find，通过它去设置检查点，自动在回放的脚本中搜索指定信息，如果找到则通过，如果找不到就是失败。

举个Demo，用LR自带的例子，在登录系统以后，设置检查点，查看系统会给出什么返回。

设置检查点的方式，在Page View视图中选择需要检查的文字，右键选择添加，如下：

如果页面中未出现检查点设置的文本或者图片，则出现错误信息

三、事务与检查点应运

首先录制一个登录的脚本，这里我们对业务熟悉，就直接使用手动插入事务的处理方法，通过鼠标右键，在需要插入事务的地方选择Insert->Start Transaction/End Transaction

插入事务后再次运行脚本，事务以Pass结束，持续时间为0.0556，浪费时间为0.0016s

说明:这里如果是录制时插入事务，那么生成的事务时间需要减去思考时间后，才是事务真正的响应时间。

在事务的脚本中，我们插入检查点，检查点插入的位置通常是放在事务的内部，这样便于理解检查点的作用，检查点函数自身消耗的时间会被事务自动排除。

如果脚本能正确进入Web Tour Welcome页面，那么执行成功，出现下面提示

【补充说明】:与事务相关的函数还包括以下五种:

lr_get_transaction_duration()//获得对应事务到达函数运行位置时持续的时间

lr_get_transaction_duration()//获得对应事务到达该函数运行位置时的waste时间

lr_get_transaction_duration()//为一个事务添加waste时间

lr_get_transaction_duration()//将一个事物暂停，该函数后面的操作都不会被记入事务时间

lr_get_transaction_duration()//将暂停的事务恢复

Golang 并发 SQL 事务

【中文标题】Golang 并发 SQL 事务

【英文标题】：Golang Concurrent SQL Transactions

【发布时间】：2015-10-19 20:52:32

【问题描述】：

遇到并发和 SQL 事务的问题。我有下面的（存根）代码（为了清楚起见，错误检查和删除）：

dao, _ := sql.Open("postgres", args)

tx1 := dao.Begin()
res, _ := tx1.Exec("UPDATE <...>", args...)
// error check

tx2 := dao.Begin()
res, _ = tx2.Exec("UPDATE <same>", args...)

_ = tx1.Commit()

_ = tx2.Commit()

这发生在单元测试中。这个想法是强制并发失败，因为两个 Exec 正在尝试更新同一行，以确保给出正确的冲突错误响应。但是，第二个 Exec 永久阻塞。

据我所知，这种类型的阻塞只应该在数据库没有数据库连接时发生，但事务都应该在它们自己的（独占）连接中运行，我没有设置任何地方的最大连接数（我也尝试将其设置为 100，没有效果）。

这是奇怪的部分。如果我将 tx2 Exec() 和 Commit() 分离到一个带有同步通道的单独 goroutine 中，以阻止主线程运行 tx1.Commit() 直到 tx2 运行它的 Exec()，同样的事情会发生，无限期地阻塞tx2.Exec()。如果我使用 time.Sleep() 而不是同步通道，则 tx2.Exec 会阻塞，直到睡眠完成并运行 tx1.Commit()，然后完成并出现预期错误 (pq: could not serialize access due to concurrent update)

我是否遗漏了有关 golang 的 SQL 包或 postgres 驱动程序如何处理连接池的内容？为什么第二个事务 Exec 阻塞直到第一个事务被提交？事务的重点不是两者可以同时运行，谁先提交（或者是开始？）谁赢？

【问题讨论】：

postgres 使用什么包？我认为您的问题与我现在已删除的答案中的内容相似，但是我的语言肯定是错误的。从Open 返回的*DB 对象可用于管理多个连接，您的驱动程序很可能有一个限制或不设计为打开新连接每个驱动程序都有自己的实现，可以找到它们的列表这里; github.com/golang/go/wiki/SQLDrivers

github.com/lib/pq 我查看了源代码，它似乎没有我能找到的任何限制。据我所知，通常鼓励司机让 golang 处理池化。

嗯我不确定，但如果你看这里的源代码，似乎大部分责任都在驱动程序上； golang.org/src/database/sql/sql.go?s=5752:6728#L211

【参考方案1】：

经过进一步研究，看起来这实际上不是 Golang 或 SQL 或 PQ 包的问题。这是 PostgreSQL 中固有的（并且是设计的）行为：

UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE 命令在搜索目标行方面的行为与 SELECT 相同：它们只会找到在命令开始时提交的目标行。但是，这样的目标行在找到时可能已经被另一个并发事务更新（或删除或锁定）。在这种情况下，可能的更新程序将等待第一个更新事务提交或回滚（如果它仍在进行中）。

http://www.postgresql.org/docs/9.1/static/transaction-iso.html

所以这个块是在 Postgres 中发生的，而不是在 Go 中。这可以通过运行并发事务来确认，这些事务使用psql 在不同的终端中更新（或插入或删除等）相同的记录。第二个 Update/Insert/Delete 将阻塞，直到调用第一个的事务调用 COMMIT 或 ROLLBACK。

【讨论】：

附带说明，如果您想让它在无法获得锁的情况下不等待，那么您可以将NOWAIT 添加到查询中。来源：***.com/questions/23702284/…

噢噢噢，这也很方便。我必须记住这一点。谢谢，@MatthewClark！