单笔事务为什么在vugen跑的时间比controller中单用户单迭代跑的时间长？

lightcabbage

调用window socket的api封装成DLL，lr进行加载，进行socket通信，事务为发送一个请求包至接收到回复包为止
在vugen中事务开始和事务结束的时候调用lr_log_message("CurrentTime: %s",lr_eval_string("{CurrentTime}"));打印当前时间，精确到毫秒，点运行时间间隔200多毫秒
生成场景，场景中跑1个用户1次迭代，即仅一个事务，lr事务响应时间图中显示响应时间为30多毫秒，抓包看到的发送和回复的时间间隔为30多毫秒，基本与场景一致。
多次测试都是这个结果，研发问vugen里怎么那么长时间，怀疑脚本处理有问题。
另，lr_think_time已忽略

lightcabbage

有人遇到过这种情况吗，场景跟vugen运行原理有什么区别吗还是其他什么原因？

lightcabbage

各位大侠，帮忙看看什么原因啊，传说中云层哥呢，这是普遍这个，还是就是这份脚本这个，大家也可以试一下自己的脚本，是不是也是这种情况呢，

lightcabbage

各位大侠，帮忙看看什么原因啊，传说中云层哥呢，这是普遍这个，还是就是这份脚本这个，大家也可以试一下自己的脚本，是不是也是这种情况呢，

奔雷

你可以检查一下controller中的run-time-settings设置是否与Virtuall user Generator中的完全一致

云层

场景运行确实比vugen运行快，主要是和vugen的调试以及animated run有关系

奔雷

可以参照这个：Problem #2 – accuracy of response time measurements

As well as the possibility of very large logs distorting your response time measurements by slowing down VuGen, running a script in VuGen is far slower than running the same script through the LoadRunner agent (mmdrv.exe which is used by LoadRunner Controller and by BAC). The overhead can be reduced by disabling “Animated Run” and “Output Window”, but there should still be a significant difference.

lightcabbage

谢谢云层，谢谢奔雷，是跟vugen的animated run模式等有关，根据大家的指引又去查阅相关资料，设置成 non animated run模式后vugen打印出来的时间间隔减少很多，疑惑解决，也进一步了解了loadrunner。
多谢各位高手帮忙解疑！

mr_hanxd

学习了。谢谢楼主和各位大侠。