记客户端请求超时分析过程
2017-07-14 10:17
141 查看
请求处理过程描述
服务端 使用 框架 加载 业务so,并未业务so创建协程处理,处理完成后给出 响应。so入口函数接收(const Type&in, Type &out,Type &extend),是否给出响应的前提是 out里面要有 业务so的处理结果,即 out 不能是空的。这样处理的 原因是 有些客户端 只关心 消息是否被服务端收到,不关心处理结果,这时 服务端在收到 请求后 直接发送响应告诉 客户端 收到消息了, 而服务端业务so处理 完消息后 置out为空,就不会再次向同一笔请求 发送响应.
框架调用业务so伪码:
try
{
loadso;
proc_func=get_symbol:入口函数
proc_func(in,out,extend);
}
catch(...)
{
printf "unkow exception"
}
问题点:
业务现网请求消息20%超时,服务端框架日志里有 “unkow exception”,但因为框架要处理很多业务,框架日志是公用的,不能确认"unkow exception”是不是超时请求引起的。
调整框架日志和业务so级别 为debug,框架调用业务so会输出两条接口日志(req,ans);
分析
a.怀疑是坏的请求,框架解析请求失败。根据请求里关键字,查看接口日志,发现只有req,没有ans,可以确定 框架接收到了请求,说明网络没问题(在进行这步是可以进行抓包,和有80%成功率),并且请求没问题。
b.业务so 有该请求的运行日志,发现运行到某 特定行后 就不往下处理,没产生core文件;可以确认问题不在框架,结合框架产生的异常异常日志,说明 业务so 产生了异常。
c.从业务so输出的最后一条debug日志点 往下分析,异常一定是后续产生的;逐行代码分析,重点关注可能抛出异常的函数(老司机一眼看出来,牛),最终锁定在string str.substr(pos),该函数原型为
string substr(size_t pos=0,size_t len=npos)const;
If this is greater than the string length, it throws out_of_range.
总结
a.发现现网问题,先向直接领导汇报,说自己正在处理,领导可以帮助协调资源,评估影响。
b.打开日志级别到debug,所有日志都要打开。(刚开始没有打印接口日志,导致框架没输出req,不能确定是不是框架没收到消息.)
c.确定请求处理的最后几行代码。逐行分析.(有经验老司机,一眼就看出来问题代码行)
d.建议框架既然捕获了异常,就输出标准异常的详情.e.what(),catch(exception e){} catch(...){}
e.业务so 使用guard 类 局部对象 在析构函数中判断 out 是否为空,以判断是不是异常退出,保证业务so 因业务异常退出时 能输出日志,有据可查. 同时guard 内也可以进行 资源释放回收,防止资源泄露.
服务端 使用 框架 加载 业务so,并未业务so创建协程处理,处理完成后给出 响应。so入口函数接收(const Type&in, Type &out,Type &extend),是否给出响应的前提是 out里面要有 业务so的处理结果,即 out 不能是空的。这样处理的 原因是 有些客户端 只关心 消息是否被服务端收到,不关心处理结果,这时 服务端在收到 请求后 直接发送响应告诉 客户端 收到消息了, 而服务端业务so处理 完消息后 置out为空,就不会再次向同一笔请求 发送响应.
框架调用业务so伪码:
try
{
loadso;
proc_func=get_symbol:入口函数
proc_func(in,out,extend);
}
catch(...)
{
printf "unkow exception"
}
问题点:
业务现网请求消息20%超时,服务端框架日志里有 “unkow exception”,但因为框架要处理很多业务,框架日志是公用的,不能确认"unkow exception”是不是超时请求引起的。
调整框架日志和业务so级别 为debug,框架调用业务so会输出两条接口日志(req,ans);
分析
a.怀疑是坏的请求,框架解析请求失败。根据请求里关键字,查看接口日志,发现只有req,没有ans,可以确定 框架接收到了请求,说明网络没问题(在进行这步是可以进行抓包,和有80%成功率),并且请求没问题。
b.业务so 有该请求的运行日志,发现运行到某 特定行后 就不往下处理,没产生core文件;可以确认问题不在框架,结合框架产生的异常异常日志,说明 业务so 产生了异常。
c.从业务so输出的最后一条debug日志点 往下分析,异常一定是后续产生的;逐行代码分析,重点关注可能抛出异常的函数(老司机一眼看出来,牛),最终锁定在string str.substr(pos),该函数原型为
string substr(size_t pos=0,size_t len=npos)const;
If this is greater than the string length, it throws out_of_range.
总结
a.发现现网问题,先向直接领导汇报,说自己正在处理,领导可以帮助协调资源,评估影响。
b.打开日志级别到debug,所有日志都要打开。(刚开始没有打印接口日志,导致框架没输出req,不能确定是不是框架没收到消息.)
c.确定请求处理的最后几行代码。逐行分析.(有经验老司机,一眼就看出来问题代码行)
d.建议框架既然捕获了异常,就输出标准异常的详情.e.what(),catch(exception e){} catch(...){}
e.业务so 使用guard 类 局部对象 在析构函数中判断 out 是否为空,以判断是不是异常退出,保证业务so 因业务异常退出时 能输出日志,有据可查. 同时guard 内也可以进行 资源释放回收,防止资源泄露.
相关文章推荐
- Kafka scala客户端在broker宕机对发送请求超时问题分析与方案
- 请教:“请求验证过程检测到有潜在危险的客户端输入值”这样的错误
- 捕捉 Asp.net ajax 客户端请求过程
- tomcat原理,一个客户端请求的处理过程
- Android应用程序请求SurfaceFlinger服务创建Surface的过程分析
- Django的请求处理过程分析
- BT源代码学习心得(十五):客户端源代码分析(下载过程中的块选取策略)
- Web 服务器处理客户端请求过程
- [转]: ASP.NET对请求处理过程的操作与分析
- asp.net请求处理过程分析
- Android应用程序请求SurfaceFlinger服务创建Surface的过程分析
- 各版本IIS下ASP.net请求处理过程分析第1/3页
- ArcGis Server ADF Toolbar与Map的客户端和服务端交互过程分析2
- ArcGis Server ADF Toolbar与Map的客户端和服务端交互过程分析1
- BT客户端源码分析之七:客户端与tracker通信过程
- SharpStreaming项目开发纪实:客户端请求获取流的大致过程
- BT客户端源码分析之八:BT对等连接的建立过程
- asp.net中webservice请求发送原理和过程的初步分析[原]
- 客户端请求WEB页面的过程
- Red5源代码分析如何响应rmpt的请求 – 关键类及其初始化过程【转载】