LR函数判断HTTP返回状态

最新推荐文章于 2024-07-30 16:07:28 发布
最新推荐文章于 2024-07-30 16:07:28 发布
阅读量1.7k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 性能测试 文章标签： action url web html
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lxlmj/article/details/7612519
本文介绍了一种利用LoadRunner中的web_get_int_property函数来获取HTTP响应码的方法，并通过示例代码展示了如何根据返回的状态码判断HTTP请求是否成功。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

web_get_int_property()的应用
 
Action()
{
int HttpRetCode;
       web_url("www.baidu.com",
              "URL=http://www.baidu.com/",
              "Resource=0",
              "RecContentType=text/html",
              "Referer=",
              "Snapshot=t1.inf",
              "Mode=HTML",
              LAST);

    HttpRetCode =web_get_int_property(HTTP_INFO_RETURN_CODE);

if (HttpRetCode == 200)
       lr_log_message("请求成功！");
       else
       lr_log_message("请求失败！ ");
       return 0;
}
LoadRunner脚本优化之服务器返回内容正确性判断
搜狗测试
04-23 3926
之前用LoadRunner调试返回结果检查时，遇到了一个有趣的问题，在此分享出来，以后用到的同学参考下，少走几步弯路~ 脚本逻辑是这样的： 1、 用web_reg_save_param函数拿到服务器返回的请求中Content-Length的值。 2、 判断服务器返回的Content-Length值是否等于1840（正确情况下应该等于1840），如果等于，就输出成功，如果不等于，就
LR中如何添加事务，参数化，检查点，集合点，思考时间等
qq_42729018的博客
07-06 2244
1.事务 事务的定义 添加事务(Transaction) 为了衡量某个action的性能，需要在action的开始和结束位置插入这 样一个范围，这就定义了一个事务 LR运行到该事务的开始点时，LR就会开始计时，直到运行到该事务的结束点，计时结束, 这个过程中得到的时间即为一个事务时间。通常事务时间所反映的是一个操作过程的响 应时间。 添加事务过程 我们在录制脚本的过程中，可以通过录制面板的事务按钮...
LR中判断HTTP返回状态码
Abby312的博客
08-30 2097
如下图：
转:LR中判断HTTP返回状态
panpanli的专栏
04-05 883
有天，有个人问：我在做b/s测试，请问如何保存从服务器传回来的http头的信息，怎么能得到http状态，和状态200进行比较？后来，我给出的代码如下：Action(){int i; // [WCSPARAM WCSParam_Text1 3 200] Parameter {WCSParam_Text1} created by Correlation Studioweb_reg_save_param
loadrunner 返回值验证
tupuo的专栏
11-12 1245
lr_start_transaction("test"); ...
lr安装失败检测到计算机,求助大神LR返回错误HTTP Status-Code=400
weixin_39633113的博客
07-28 588
求助大神LR返回错误HTTP Status-Code=400更新时间：2019-05-30 07:38最满意答案个一个请求报文的格式，请求行和请求头部都可以通过 HttpWebRequest 对象的一些属性来添加，具体有哪些自己百度一下吧，笔者也不是十分清楚，这里就不给出资料了请求数据需要自己 使用字符串拼接，下面给出笔者在这次事件中得到的经验---------------------------...
lr11常见问题及解决方案
07-12
- 出现诸如500、502或504等HTTP状态码错误时，通常表示应用程序存在问题。此时应与开发团队沟通，共同定位问题所在。 3. **超时报错** - 下载超时错误通常包含"120s download timeout"等信息。此类错误通常与实际...
loadrunner常用函数_LoadRunner-常用的函数
weixin_42131890的博客
12-24 1196
LoadRunner中，常用的函数有很多，这里只介绍编写性能测试脚本过程中那些必然用到的函数。本文重点关注这些典型函数的应用场合及注意点，至于函数详细使用说明请参见LoadRunner帮助文档。1.1.1.事务相关1.1.1.1. lr_start_transaction/lr_end_transaction功能：事务开始/结束标记。应用场合：需要统计某一段代码块执行所需要的时间，这两个函数需要成...
【性能测试】第二节.loadrunner工具介绍（LR）
未央的博客哟
07-13 1437
一、VUG：虚拟用户发生器1.1 实现作用主要用来生成性能测试脚本（写脚本）（1）作用：创建和设计测试场景，运行测试脚本，监控场景运行，收集测试过程的数据（2）打开方法：① 直接点击桌面的controller图标or ② 在VUG中Tools =》 Create Controller Scenario。
Loadrunner12常用函数
weixin_44149742的博客
07-30 387
7、LoadRunner中的web_add_header（“User-Agent”，“MercuryBrowser 1.0”）该脚本仅将此用户代理信息与下一个HTTP请求相关联。6、LoadRunner中的web_add_auto_header()函数用于向所有后续的HTTP请求中自动添加指定的标头。5、这个函数的主要作用是限制HTML字符串的长度，‌以避免数据长度超过这个限制而导致关联失败。3、通过截取接口返回的内容进行转码输出(解决接口响应中文为乱码的问题)2、将变量转为字符串类型。
如何利用LoadRunner判断HTTP服务器的返回状态[原]
qqzhouzhou的专栏
01-29 356
ruotian() 发表于 2009-01-28 关键词: 可以利用LR的内置函数web_get_int_property判断HTTP服务器的返回状态, 如下是一个简单的例子:#include "web_api.h" Action(){int HttpRetCode;web_url("my_home","URL=http://myhomeurl","TargetFrame=_TOP", LAST...
利用LoadRunner判断HTTP服务器的返…
Cheers Li 软件测试博客
09-15 1977
利用LoadRunner判断HTTP服务器的返回状态 第一种方法：是利用LR的内置函数web_get_int_property。 举例： #include "web_api.h" Action() { int HttpRetCode; web_url("网易",        "URL=http://www.163.com",        "TargetFrame=_TOP",        L
Loadrunner 判断事务是否成功的几个方法
figo8875的专栏
07-31 1452
在LR 中往往需要关联response中的值来判断请求是否发送成功，可以使用以下几种方法： 一、根据登录成功界面是否出现相应的元素来判断： 1、判断关联到的字符串是否为空， if (strlen(lr_eval_string("{param}")) == 0); 2、判断关联的字符串是否跟期望的值相同， if(strcmp(lr_eval_string("{param}"), "expected...
LR中判断HTTP返回状态
Zee的原创
03-22 5292
 有天，有个人问：我在做b/s测试，请问如何保存从服务器传回来的http头的信息，怎么能得到http状态，和状态200进行比较？后来，我给出的代码如下：Action(){int i;       // [WCSPARAM WCSParam_Text1 3 200] Parameter {WCSParam_Text1} created by Correlation Studio
web门户登录成功校验LR脚本（web_reg_find应用）
weixin_30698527的博客
10-17 186
原创vuser脚本片段： lr_start_transaction("trans_login");//设置检查的内容，在savecount变量里面记录查找到的次数web_reg_find("Text=欢迎您","SaveCount=loginss_count",LAST); //登录（登录录制的自动生成代码）web_submit_data("loginAction.do;jsession...
【LoadRunner】查看脚本请求日志和服务器返回值方法
深圳-雄少（XZee）
09-05 6762
查看LoadRunner脚本请求日志和服务器返回值方法 1、  查看所有请求日志和请求响应信息： 采用LoadRunner工具Run-time settings或按键盘F4，选择LOG设置,选择Extended log->Data returned by server和Parameter substitution，就可以搞定，但是这里设置是记录所有请求的日志。 详细介绍Extended lo
Lr 常用字符串函数，判断事务是否成功
he_jian1的专栏
11-17 5357
1)strcat编辑本段回目录 　　char *strcat ( char *to, const char *from ); 　　功能：链接两个字符串。 　　例子： 　　这个例子是用strcat链接字符串：Leeing和 @163.com.cn 　　脚本如下： char test[1024], *a = "@163.com.cn"; strcpy(test, "
Loadrunner之HTTP接口测试
weixin_30478923的博客
12-31 187
Loadrunner之HTTP接口测试 　　接口测试的原理是通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一个过程。测试http接口和测试webservice接口一样，需要开发提供相关接口及参数说明，当然如果条件不允许，我们也可以通过IE浏览器插件httpwatch或者火狐浏览器的firebug等工具来捕获操...
lr函数--web_get_int_property（记录HTTP响应信息）
splenday的专栏
07-26 641
lr函数--web_get_int_property 一、函数用途 记录http响应的信息 二、函数属性 1.http_info_return_code:     返回http代码 2.http_info_download_size：返回页面字节数 3.http_info_download_time：返回页面下载时间 三、例子 Action() { int HttpRetC
public class Tools implements ToolCallingManager { @Override public List<ToolDefinition> resolveToolDefinitions(ToolCallingChatOptions chatOptions) { return null; } @Override public ToolExecutionResult executeToolCalls(Prompt prompt, ChatResponse chatResponse) { return null; } }现在我需要在工具回调进行返回数据时，如果工具返回的是流式数据，则对其进行处理，以便大模型能解析出该数据
最新发布
07-10
<think>我们正在处理一个关于在ToolCallingManager接口的executeToolCalls方法中处理流式数据的问题。根据引用[2]中的描述，流式处理通常涉及SSE（Server-Sent Events）或WebFlux的SseEmitter。我们的目标是在工具回调中处理流式数据，以便大模型能够解析。 关键点： 1. 我们需要在executeToolCalls方法中处理流式数据，这意味着我们可能不会一次性获取所有数据，而是分块（chunk）接收。 2. 大模型需要能够解析这些流式数据，因此我们需要将流式数据逐步传递给大模型，或者将流式数据整合成模型可以理解的格式。 根据引用[1]和[2]的提示： - 引用[1]提到，当大模型判断需要调用Function（即Tool）时，会返回Function名称和参数，然后我们执行Function，并将结果再次封装到Prompt中发送给AI。 - 引用[2]描述了流式对话的处理流程，包括使用SseEmitter和EventSourceListener，在onEvent回调中处理数据（如写入数据库）以及考虑TokenSize等。 因此，在executeToolCalls方法中处理流式数据，我们可以考虑以下步骤： 1. 识别工具调用：根据大模型返回的请求，解析出需要调用的工具（函数）和参数。 2. 执行工具调用：调用相应的工具，并获取数据流（例如，通过一个返回流式数据的服务）。 3. 处理流式数据：使用响应式流（如Reactor的Flux）或SSE来逐步读取数据。 4. 将流式数据转换为大模型可解析的格式：将每个数据块（chunk）封装为模型可以理解的格式（例如，将每个数据块作为一次部分响应发送给模型，或者等待流式数据结束，将完整数据返回给模型）。注意，大模型可能期望一个完整的响应，也可能支持分块响应，这取决于具体实现。 然而，问题在于ToolCallingManager接口的executeToolCalls方法通常期望一个同步的响应（即一次性返回所有数据）。但我们需要处理流式数据，所以可能需要调整设计。 解决方案思路： 我们可以设计一个异步的处理流程，在流式数据产生时，逐步将数据发送给大模型。但是，由于大模型在等待工具调用的结果，我们可能需要将流式数据收集完整后再返回，或者采用分步交互（多次调用大模型）的方式。 但根据引用[1]的描述，工具调用的结果是一次性封装到Prompt中再发送给AI的。因此，如果我们必须处理流式数据，那么我们需要等待整个流式数据结束，将完整数据返回给大模型。 另一种方案是，如果大模型支持流式工具调用（即工具调用结果可以分多次返回），那么我们可以将流式数据拆分成多个部分，多次调用大模型。但这需要大模型API的支持。 考虑到当前问题，我们假设大模型需要完整的工具调用结果。因此，在executeToolCalls方法中，我们需要将流式数据收集完整，然后返回。 实现步骤（伪代码）： 1. 解析工具调用请求，获取工具名称和参数。 2. 根据工具名称找到对应的工具执行器，并传入参数执行，得到一个流式数据源（例如Flux<String>或InputStream）。 3. 订阅流式数据源，将数据块收集到一个缓冲区（如StringBuilder或ByteArrayOutputStream），直到流结束。 4. 将收集到的完整数据作为工具调用的结果返回。 但是，如果流式数据量非常大，或者需要很长时间，可能会导致内存溢出或超时。因此，我们需要考虑设置超时和缓冲区大小限制。 另一种更高级的做法是，在流式数据产生的同时，逐步将数据发送回大模型（如果大模型支持分块接收工具调用结果）。但这需要大模型API支持流式工具调用，目前可能不常见。 根据问题描述，我们假设需要将流式数据整合后返回。因此，我们可以这样实现： ```java public class MyToolCallingManager implements ToolCallingManager { @Override public ToolExecutionResult executeToolCalls(List<ToolCall> toolCalls) { // 假设一次只处理一个工具调用，或者需要合并多个工具调用的结果 // 这里我们假设每次只调用一个工具 ToolCall toolCall = toolCalls.get(0); String toolName = toolCall.getName(); Map<String, Object> parameters = toolCall.getParameters(); // 根据工具名选择不同的工具执行器 if ("streamingDataTool".equals(toolName)) { // 假设我们有一个流式数据服务 Flux<String> dataStream = streamingDataService.getStreamingData(parameters); // 收集流式数据 List<String> chunks = dataStream.collectList().block(); // 使用block等待流完成，注意：这在非响应式环境中可能阻塞线程 String fullData = String.join("", chunks); // 创建工具执行结果 return new ToolExecutionResult(toolCall.getId(), fullData); } // 其他工具... } } ``` 但是，上述代码使用了block()，这在响应式编程中是不推荐的，因为它会阻塞线程。在响应式环境中，我们应该返回一个Mono<ToolExecutionResult>，但接口可能要求同步返回。因此，我们需要根据实际情况调整。 如果我们的系统是响应式的（如使用WebFlux），那么我们可以将接口设计为异步的。但是，如果接口必须是同步的，那么我们就必须阻塞等待流完成。 另一种设计：使用异步回调（但接口设计可能不支持） 考虑到问题中要求实现ToolCallingManager接口的executeToolCalls方法，我们假设该方法需要同步返回结果。因此，我们只能阻塞等待流式数据完成。 但是，我们可以设置超时： ```java String fullData = dataStream.collectList() .timeout(Duration.ofSeconds(30)) // 设置超时时间 .block() .stream() .collect(Collectors.joining()); ``` 注意：阻塞操作在响应式应用中会降低性能，应谨慎使用。 如果流式数据量很大，我们可能无法一次性加载到内存，那么我们可以考虑将数据写入临时文件，然后返回文件的引用（如路径或URL）给大模型。但需要确保大模型能够理解这个引用并读取文件内容。 总结： 在executeToolCalls方法中处理流式数据，我们有两种主要方式： 1. 等待流式数据结束，将完整数据返回（适合数据量不大，且大模型需要完整数据的场景）。 2. 返回一个数据流的引用（如文件路径、URL或流ID），然后由大模型通过其他方式读取（需要大模型支持）。 根据引用[2]中提到的，他们通过另外的HTTP API触发写入操作，并且将数据写入数据库。因此，我们也可以考虑在流式数据到达时，将数据写入数据库（或缓存），然后只返回一个标识符（如记录ID）给大模型。这样，大模型可以通过这个标识符在后续步骤中获取数据。 但注意，引用[1]提到，工具调用的结果会再次封装到Prompt中发送给AI。因此，如果返回的是标识符，那么大模型在后续的Prompt中只能看到标识符，而看不到具体数据。除非大模型能够主动通过另一个工具调用去读取数据，但这需要多次交互。 因此，我们需要根据实际业务场景权衡。 由于问题中没有明确大模型是否支持多次交互，我们假设需要一次性返回数据。因此，我们采用第一种方式：收集完整数据后返回。 但是，如果数据量非常大，我们可能需要第二种方式（返回引用），并设计大模型能够使用另一个工具来读取数据（例如，提供一个读取数据的工具，通过标识符读取数据块）。这样，大模型可以分多次读取数据，避免一次性加载大量数据。 考虑到问题复杂性，这里我们提供两种方案，并说明在executeToolCalls中如何实现。 方案一：收集完整数据（适合小数据量） 如上所示。 方案二：返回数据引用（适合大数据量） ```java public ToolExecutionResult executeToolCalls(List<ToolCall> toolCalls) { ToolCall toolCall = toolCalls.get(0); // ... 解析参数 Flux<String> dataStream = streamingDataService.getStreamingData(parameters); // 生成一个唯一标识符 String streamId = UUID.randomUUID().toString(); // 将流式数据存储到缓存或数据库，并关联streamId // 这里我们异步存储，因为流式数据需要时间 dataStream.subscribe( chunk -> { // 将chunk追加到缓存（如Redis）中key为streamId的列表中 }, error -> { // 错误处理 }, () -> { // 流结束，可以设置一个完成标志 } ); // 返回引用（streamId） return new ToolExecutionResult(toolCall.getId(), streamId); } ``` 然后，我们还需要提供另一个工具（函数）来根据streamId获取数据（或数据的一部分）。这样，大模型在得到streamId后，如果需要具体数据，可以调用这个新工具。 但是，这需要大模型进行两次工具调用：第一次调用流式数据工具得到streamId，第二次调用数据读取工具获取数据（可以分块获取，也可以一次性获取全部）。 因此，在executeToolCalls中，我们返回的是streamId，而不是数据本身。 选择哪种方案取决于业务需求和数据量。 问题中要求“使其可被大模型解析”，所以只要大模型能够理解返回的内容（无论是完整数据还是引用）即可。因此，我们需要在定义工具（Function）时，描述清楚返回值的类型和含义。 例如： 方案一：工具返回类型为字符串，描述为“流式数据的完整内容”。 方案二：工具返回类型为字符串，描述为“流式数据的引用ID，可用于通过getStreamData工具获取数据”。 最后，根据引用[2]中提到的，在流式处理中，他们通过EventSourceListener的onEvent回调将数据写入数据库。因此，我们可以借鉴这种思路，在流式数据到达时，将数据写入存储，然后返回存储的引用。 综上所述，我们可以在executeToolCalls方法中启动流式数据的处理，并立即返回一个引用（如streamId），然后由大模型在后续步骤中根据需要读取数据。这样，executeToolCalls方法不会阻塞，但需要异步处理流式数据。 然而，由于executeToolCalls方法需要返回一个结果（ToolExecutionResult），我们不能等待流式数据全部处理完（因为可能耗时很长），所以返回引用是更合理的。 因此，我们采用方案二。 实现细节： 1. 在executeToolCalls中，启动流式数据的订阅，并将数据写入一个缓存（如Redis List），同时设置一个过期时间。 2. 返回streamId。 3. 提供另一个工具（例如getStreamData），它接收streamId和可选的块索引（或范围）参数，然后从缓存中读取数据。 注意：由于流式数据是异步写入的，所以在返回streamId时，数据可能还没有完全写入。因此，大模型在后续调用getStreamData时，可能会读取到部分数据。我们可以在流结束时标记完成状态，这样大模型可以知道何时数据完整。 但是，这增加了复杂性。如果大模型需要完整数据才能进行下一步，那么它需要轮询直到数据完整。或者，我们可以在流式数据完全写入后，通过事件通知大模型，但这超出了工具调用的范围。 因此，在简单场景下，如果数据量不大，方案一更简单直接。在数据量大或需要避免阻塞的场景下，方案二更合适。 由于问题没有明确数据量大小，我们给出两种方案，并建议根据实际情况选择。 下面，我们以方案二为例，给出一个更完整的实现示例： ```java public class MyToolCallingManager implements ToolCallingManager { private final StreamingDataService streamingDataService; private final StreamDataCache streamDataCache; // 自定义缓存接口 @Override public ToolExecutionResult executeToolCalls(List<ToolCall> toolCalls) { ToolCall toolCall = toolCalls.get(0); String toolName = toolCall.getName(); Map<String, Object> parameters = toolCall.getParameters(); if ("streamingDataTool".equals(toolName)) { String streamId = UUID.randomUUID().toString(); // 初始化缓存，创建一个空列表 streamDataCache.create(streamId); // 异步获取流式数据并写入缓存 Flux<String> dataStream = streamingDataService.getStreamingData(parameters); dataStream.subscribe( chunk -> streamDataCache.append(streamId, chunk), error -> streamDataCache.markAsFailed(streamId, error), () -> streamDataCache.markAsCompleted(streamId) ); // 返回streamId return new ToolExecutionResult(toolCall.getId(), Collections.singletonMap("streamId", streamId)); } else if ("getStreamData".equals(toolName)) { // 这是另一个工具，用于读取数据 String streamId = (String) parameters.get("streamId"); List<String> data = streamDataCache.get(streamId); return new ToolExecutionResult(toolCall.getId(), Collections.singletonMap("data", data)); } // ... 其他工具 } } ``` 注意：这里我们返回了一个Map，其中包含streamId。这样，大模型可以解析这个Map，然后根据需要使用getStreamData工具来读取数据。 但是，工具调用的结果需要符合大模型期望的结构。因此，我们需要在定义这两个工具时，明确说明参数和返回值的结构。 例如： 工具1：streamingDataTool - 描述：启动一个流式数据请求，返回一个包含streamId的对象。 - 参数：根据实际需求定义 - 返回类型：对象，包含属性streamId（字符串） 工具2：getStreamData - 描述：根据streamId获取流式数据的内容 - 参数：streamId（字符串） - 返回类型：对象，包含属性data（字符串列表） 这样，大模型就可以先调用streamingDataTool，得到streamId，然后调用getStreamData来获取数据（可能多次调用，如果支持分页的话）。 但是，如果流式数据还在写入中，getStreamData可能返回部分数据。因此，我们还可以在缓存中记录流的状态（进行中、完成、失败）。然后，在getStreamData工具中，我们可以返回数据和状态（例如，包含一个isCompleted属性）。 这样，大模型可以判断是否还需要继续调用getStreamData来获取更新的数据（直到isCompleted为true）。但注意，这要求大模型能够保存上下文，并且主动进行多次调用。 由于多次工具调用会增加交互次数，我们需要权衡。 结论： 在executeToolCalls方法中，我们可以通过异步处理流式数据，并返回一个引用（streamId）来实现流式数据的处理。然后，通过另一个工具调用来读取数据。这样，大模型可以通过多次交互逐步获取数据，避免了一次性加载大量数据。 以上是两种解决方案，请根据实际业务场景选择。</think>在实现 `ToolCallingManager` 接口的 `executeToolCalls` 方法中处理流式数据，需结合响应式编程和事件驱动机制。以下是分步实现方案： ### 核心步骤 1. **解析工具调用请求** 从大模型响应中提取工具名称和参数： ```java public List<ToolExecutionResult> executeToolCalls(List<ToolCall> toolCalls) { return toolCalls.stream().map(toolCall -> { String toolName = toolCall.getName(); Map<String, Object> params = toolCall.getParameters(); // ... }).collect(Collectors.toList()); } ``` 2. **流式数据源接入** 使用 WebFlux 的 `WebClient` 连接流式数据源（如 SSE 服务）： ```java WebClient client = WebClient.create(); Flux<String> dataStream = client.get() .uri("https://stream-data-source") .retrieve() .bodyToFlux(String.class); // 转换为响应式流 ``` 3. **流式数据处理** 通过 `SseEmitter` 或 `Flux` 分块处理数据，并实时回调： ```java SseEmitter emitter = new SseEmitter(); dataStream.subscribe( chunk -> { // 1. 处理数据块（如解析、过滤） String processed = processChunk(chunk); // 2. 写入数据库（通过内部API） writeToDatabase(processed); // 3. 发送给大模型 emitter.send(processed); }, error -> emitter.completeWithError(error), () -> { storeTokenMetrics(); // 流结束时计算Token占用 emitter.complete(); } ); return emitter; ``` 4. **大模型交互封装** 将流式结果封装为大模型可解析的结构： ```java ToolExecutionResult result = new ToolExecutionResult( toolCall.getId(), new ToolResponse( "STREAMING", // 标识流式响应 Map.of("emitter", emitter, "streamId", streamId) ) ); ``` ### 关键优化点 1. **异步回调机制** 使用 `EventSourceListener` 处理流事件： ```java eventSource.setListener(new EventSourceListener() { @Override public void onEvent(String event, String data) { // 触发工具函数处理逻辑 toolService.process(data); } }); ``` 2. **资源管理** - **超时控制**：`SseEmitter.setTimeout(30_000L)` - **错误处理**：`onFailure` 回调中回滚事务 - **缓存释放**：流结束时清理 `streamId` 关联资源 3. **元数据记录** 在流关闭时入库关键信息： ```java void onClosed() { TokenCounter.calculate(dataStream); // 计算Token占用 db.insert("stream_metrics", streamId, tokenCount); } ``` ### 架构示意图 ```mermaid graph LR A[大模型请求] --> B(ToolCallingManager) B --> C{解析工具调用} C --> D[WebClient接入SSE流] D --> E[Flux数据流] E --> F[分块处理] F --> G[数据库写入API] F --> H[实时发送至大模型] H --> I[模型增量解析] I --> J[返回最终结果] ``` ### 注意事项 1. **状态一致性** 流处理需保证幂等性，建议为每个数据块附加唯一 `chunkId`，避免重复处理。 2. **背压控制** 使用响应式背压策略防止数据过载： ```java dataStream.onBackpressureBuffer(1000) // 设置缓冲区 .delayElements(Duration.ofMillis(50)); // 延迟处理 ``` 3. **大模型兼容性** 返回结构需匹配模型预期格式，例如 OpenAI 工具调用要求 `tool_call_id` 和 `content` 字段[^1]。 此方案通过响应式流处理实现了： - **实时增量处理**：分块数据即时处理，无需等待完整响应 - **资源高效利用**：异步非阻塞模型避免线程阻塞 - **端到端可追溯**：Token 计量和错误处理保障可靠性 [^1]: 工具调用流程中需严格匹配模型要求的参数结构和返回格式 [^2]: SSE 连接需正确处理 `onEvent`、`onClosed` 等生命周期事件
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值