loadrunner。C
lr_output_message ("################### %s ##############################",lr_eval_string ("{username}"));web_set_max_html_param_len("20000000000");
web_reg_save_param ("count",
"LB=",
"RB=",
"SEARCH=BODY",
LAST);
web_submit_data ("download.file",
"Action=http:?fileUuid=4f154207ab017bffd4c65370",
"Method=POST",
"EncType=multipart/form-data",
"RecContentType=text/html",
"Referer=",
"Mode=HTML",
ITEMDATA,
LAST);
// web_submit_data("download.file",
// "Action=http://1.1.1.10/omm_spc/caseFile/download.do?fileUuid={fileid}",
// "Method=POST",
// "EncType=multipart/form-data",
// "RecContentType=text/html",
// "Referer=",
// "Mode=HTML",
// ITEMDATA,
// LAST);
strcpy(filepath,
"D:\\test\\");
strcat(filepath,
fullpath);
strcat(filepath,
".doc");
flen = web_get_int_property (HTTP_INFO_DOWNLOAD_SIZE);
if (flen >0 ) {
if((file_stream = fopen(filepath, "wb")) == NULL )
// if((file_stream = fopen(fullpath, "wb")) == NULL)
{
lr_output_message ("Openfilefail !");
return -1;
}
fwrite(lr_eval_string("{count}"),flen,1 ,file_stream);
fclose(file_stream);
}
return 0;
} Action()
{
int flen ,file_stream,test;
char fullpath,filepath;
test = rand()%100;
rand();
itoa(test,
fullpath,
100);
web_url("login",
"URL=http://%%%%%%%%/j_spring_security_check?j_username={username}&j_password=12345678&_spring_security_remember_me=null",
LAST); LZ想表达啥 相当的莫名其妙 没必要这么麻烦吧 下载个文件找的资料。 9.1分析事务的响应时间
第一步，看“Transaction Performance Summary”图，确认那个事务的响应时间比较大，
超出了我们的标准。看下图，login 事务的平均响应时间最长。
然后我们再看“Average Transaction Response Time”，观察login 在整个场景运行中每一
秒的情况。从图中可以看出，login 事务的响应时间并不是一直都比较高，只是随着用户数
的增加，响应时间才明显增加的
为了定位问题，明白为什么login 事务的响应时间比较长，现在我们要分解login 事务，
分析该页面上每一个元素的性能。在上图中，选择要分解的事务曲线，然后点鼠标右键，选
择“Web Page Breakdown for login”
9.2 分解页面
通过分解页面可以得到：比较大的响应时间到底是页面的哪个组件引起的？问题出在服
务器上还是网络传输上。
这 里 为 了 解 说 各 个 时 间（比如：DNS 解析时间、连接时间、接受时间等）
下面简单说一下浏览器从发送一个请求到最后显示的全过程。
1. 浏览器向 Web Server 发送请求，一般情况下，该请求首先发送到DNS Server 把DNS
名字解析成IP 地址。解析的过程的时间就是DNS Resolution。这个度量时间可以
确定DNS 服务器或者DNS 服务器的配置是否有问题。如果DNS Server 运行情况
比较好，该值会比较小。
2. 解析出 Web Server 的IP 地址后，请求被送到了Web Server，然后浏览器和Web
Server 之间需要建立一个初始化连接，建立该连接的过程就是Connection。这个
度量时间可以简单的判断网络情况，也可以判断Web Server 是否能够响应这个请
求。如果正常，该值会比较小。
3. 建立连接后，从Web Server 发出第一个数据包，经过网络传输到客户端，浏览器
成功接受到第一字节的时间就是First Buffer。这个度量时间不仅可以表示Web
Server 的延迟时间，还可以表示出网络的反应时间。 4. 从浏览器接受到第一个字节起，直到成功收到最后一个字节，下载完成止，这段时
间就是Receive。这个度量时间可以判断网络的质量（可以用size/time 比来计算
接受速率）
其他的时间还有 SSL Handshaking（SSL 握手协议，用到该协议的页面比较少）、Client
Time（请求在客户端浏览器延迟的时间，可能是由于客户端浏览器的think time 或者客户端
其他方面引起的延迟）、Error Time（从发送了一个HTTP 请求，到Web Server 发送回一个
HTTP 错误信息，需要的时间）。
熟悉了以上各个时间的含义后，我们开始看分解页面的图形。
首先看“Downlaod Time Breakdown”，可以看出login 事务分解的各个组件的大小，以
及各个组件的下载时间。
从下图可以看出，login 页面有5 个组件组成，其中next.gif 下载用的时间最长，并且几
乎所有的时间都用在了First Buffer 上，而其大小为1.256KB，并不是很大。
上图提供的组件大小的信息比较简单，更详细的信息参考“Download Component Size
Graph”。利用该图可以看出该页面各种组件的大小所占的比例关系。
同样，要看各个组件下载时间的更详细的信息，可以参考“Page Component Breakdown”。
利用该图可以看出该页面各种组件下载时间的比例关系。
选择“Component Breakdown（Over Time）”，可以以图形曲线的形式看出各个组件在场景运
行中的每秒钟的下载时间，比较具体。要看到具体的值，可以参考Page Component Breakdown
（Over Time） 然后再选择“Download Time BreakDown（Over Time）”，从中可以看出在场景运行中的每一
秒钟，组件用在传输的各部分的时间。要看到具体的值，可以参考Page Download Time
Breakdown（Over Time）
为了确认问题缘由到底是服务器还是网络，选择“Time to First Buffer Breakdown”，可以看
出Server 时间比network 时间要高的多，从而确定问题是服务器引起的。然后我们就可以参
考Web Server 的相关图表，来确定问题是由服务器的哪个部分引起。遵从这样的步骤，可
以一步步的接近问题源；如果问题由网络引起，可以参考NetWork 相关的图表，确定什么
样的网络问题是性能的瓶颈。同时可以参考“Time To First Buffer BreakDown(Over Time)”
---摘自loadrunner经典全面指南 //使用C将字符串保存到本地文件中
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void){
char filepath[] = "D:\\a.txt";
FILE *fp;
char *file_strem;
char *str = "abcdefghijklmn";
int number = strlen(str);
if((fp =fopen(filepath,"wb")) == NULL){
printf("open file fail!!!");
}
fwrite(str,sizeof(char),number,fp);
fclose(fp);
return 0;
}
页:
[1]
