ATS请求处理状态机流程(缓存命中)

在HttpSM::handle_api_return和HttpSM::set_next_state函数分别打断点,进入函数的时候分别打印t_state.api_next_action和t_state.next_action,

一个缓存命中的请求完整流程的堆栈信息如下。

Breakpoint 1 at 0x596c40: file HttpSM.cc, line 1580.

Breakpoint 2 at 0x5a8f40: file HttpSM.cc, line 6841.

[Switching to Thread 0x2b06a7472700 (LWP 15194)]

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$1 = HttpTransact::HTTP_API_SM_START

"t_state.next_action: "$2 = HttpTransact::STATE_MACHINE_ACTION_UNDEFINED

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$3 = HttpTransact::HTTP_API_SM_START

"t_state.next_action: "$4 = HttpTransact::HTTP_API_READ_REQUEST_HDR

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$5 = HttpTransact::HTTP_API_READ_REQUEST_HDR

"t_state.next_action: "$6 = HttpTransact::HTTP_API_READ_REQUEST_HDR

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$7 = HttpTransact::HTTP_API_READ_REQUEST_HDR

"t_state.next_action: "$8 = HttpTransact::HTTP_API_PRE_REMAP

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$9 = HttpTransact::HTTP_API_PRE_REMAP

"t_state.next_action: "$10 = HttpTransact::HTTP_API_PRE_REMAP

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$11 = HttpTransact::HTTP_API_PRE_REMAP

"t_state.next_action: "$12 = HttpTransact::HTTP_REMAP_REQUEST

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$13 = HttpTransact::HTTP_API_PRE_REMAP

"t_state.next_action: "$14 = HttpTransact::HTTP_API_POST_REMAP

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$15 = HttpTransact::HTTP_API_POST_REMAP

"t_state.next_action: "$16 = HttpTransact::HTTP_API_POST_REMAP

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$17 = HttpTransact::HTTP_API_POST_REMAP

"t_state.next_action: "$18 = HttpTransact::CACHE_LOOKUP

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$19 = HttpTransact::HTTP_API_POST_REMAP

"t_state.next_action: "$20 = HttpTransact::HTTP_API_READ_CACHE_HDR

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$21 = HttpTransact::HTTP_API_READ_CACHE_HDR

"t_state.next_action: "$22 = HttpTransact::HTTP_API_READ_CACHE_HDR

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$23 = HttpTransact::HTTP_API_READ_CACHE_HDR

"t_state.next_action: "$24 = HttpTransact::HTTP_API_CACHE_LOOKUP_COMPLETE

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$25 = HttpTransact::HTTP_API_CACHE_LOOKUP_COMPLETE

"t_state.next_action: "$26 = HttpTransact::HTTP_API_CACHE_LOOKUP_COMPLETE

Breakpoint 2, HttpSM::set_next_state (this=0x2b06b9400000) at HttpSM.cc:6841

6841      switch (t_state.next_action) {

"t_state.api_next_action: "$27 = HttpTransact::HTTP_API_CACHE_LOOKUP_COMPLETE

"t_state.next_action: "$28 = HttpTransact::SERVE_FROM_CACHE

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$29 = HttpTransact::HTTP_API_SEND_REPONSE_HDR

"t_state.next_action: "$30 = HttpTransact::SERVE_FROM_CACHE

Breakpoint 1, HttpSM::handle_api_return (this=0x2b06b9400000) at HttpSM.cc:1580

1580      switch (t_state.api_next_action) {

"t_state.api_next_action: "$31 = HttpTransact::HTTP_API_SM_SHUTDOWN

"t_state.next_action: "$32 = HttpTransact::SERVE_FROM_CACHE

以进入HttpSM::handle_api_return的各个state为顺序进行分析如下:

第一个state是HttpTransact::HTTP_API_SM_START,这个阶段并没有直接执HttpSM::call_transact_and_set_next_state函数。一开始执行了读请求头的函数:HttpSM::setup_client_read_request_header,这个读操作对应的事件回调函数是之前在HttpSM::attach_client_session函数中设置的HttpSM::state_read_client_request_header。在HttpSM::state_read_client_request_header函数中如果读操作执行的顺利的话,最后执行了HttpSM::call_transact_and_set_next_state,并且带了一个参数,HttpTransact::ModifyRequest函数。HttpTransact::ModifyRequest函数提取了一些请求相关的信息,最后执行TRANSACT_RETURN函数,进入下一个state。

第二个state是HttpTransact::HTTP_API_READ_REQUEST_HDR,这个阶段call执行了HttpTransact::StartRemapRequest函数,这个函数判断了如果不需要remap,直接执行TRANSACT_RETURN函数。如果需要remap,设置一些debug和监控信息之后执行TRANSACT_RETURN函数,第一个参数为HTTP_API_PRE_REMAP,第二个参数为HttpTransact::PerformRemap。

第三个state是HttpTransact::HTTP_API_PRE_REMAP,这个阶段call的函数什么都没做直接TRANSACT_RETURN函数了,第一个参数是HTTP_REMAP_REQUEST,第二个参数是HttpTransact::EndRemapRequest。随后在HttpSM::set_next_state中,执行了HttpSM::do_remap_request函数。接着又执行了一次HttpSM::call_transact_and_set_next_state函数,这次call了HttpTransact::EndRemapRequest函数,也即上一次call的函数最后TRANSACT_RETURN函数的参数在这里生效了。HttpTransact::EndRemapRequest函数本质上是分析了remap执行的情况,顺利的话最后执行的TRANSACT_RETURN函数第一个参数是HTTP_API_POST_REMAP,第二个参数是HttpTransact::HandleRequest。

第四个state是HttpTransact::HTTP_API_POST_REMAP,这个阶段call了上个state设置的HttpTransact::HandleRequest函数,判断了请求是否有效,判断了缓存是否可以被查找,最后执行了HttpTransact::StartAccessControl函数,并且以HttpTransact::StartAccessControl->HttpTransact::HandleRequestAuthorized->HttpTransact::DecideCacheLookup的调用关系最后执行了TRANSACT_RETURN函数,第一个参数CACHE_LOOKUP,第二个参数NULL。在接下来的HttpSM::set_next_state函数中,首先为continuation函数设置了回调函数HttpSM::state_cache_open_read,之后执行了HttpSM::do_cache_lookup_and_read函数,HttpSM::do_cache_lookup_and_read函数执行完了之后会触发HttpSM::state_cache_open_read函数。HttpSM::do_cache_lookup_and_read函数执行了查缓存操作,如果缓存查询命中了,HttpSM::state_cache_open_read函数的event是CACHE_EVENT_OPEN_READ,最后执行了call_transact_and_set_next_state函数,并且带了一个参数,HttpTransact::HandleCacheOpenRead函数。HttpTransact::HandleCacheOpenRead函数确认是不是真的缓存命中了,最后执行了TRANSACT_RETURN函数,第一个参数HTTP_API_READ_CACHE_HDR,第二个参数HttpTransact::HandleCacheOpenReadHitFreshness。

第五个state是HttpTransact::HTTP_API_READ_CACHE_HDR,这个阶段call了上一次TRANSACT_RETURN函数的第二个参数HttpTransact::HandleCacheOpenReadHitFreshness函数,HttpTransact::HandleCacheOpenReadHitFreshness函数判断缓存是否过期了,如果没有过期最后执行了TRANSACT_RETURN函数,第一个参数为HTTP_API_CACHE_LOOKUP_COMPLETE,第二个参数是HttpTransact::HandleCacheOpenReadHit。随后的HttpSM::set_next_state函数直接把t_state.next_action赋值给了t_state.api_next_action,赋值完了t_state.api_next_action的值为HTTP_API_CACHE_LOOKUP_COMPLETE。

第六个state是HttpTransact::HTTP_API_CACHE_LOOKUP_COMPLETE,这个阶段call了HttpTransact::HandleCacheOpenReadHit函数,这个函数判断了缓存的东西是不是可以直接返回,因为有可能需要有刷新之类的操作。如果可以直接返回,执行了HttpTransact::build_response_from_cache函数。这个函数生成了响应数据,并且将HttpSM::next_action设置为SERVE_FROM_CACHE,在HttpSM::set_next_state中设置t_state.api_next_action 为HttpTransact::HTTP_API_SEND_REPONSE_HDR

第七个state是HttpTransact::HTTP_API_SEND_REPONSE_HDR,这个阶段并没有执行HttpSM::call_transact_and_set_next_state函数,只是设置了一个回调函数就break了。函数并没有退出HttpSM::handle_api_return,HttpSM::handle_api_return函数有两个switch,第一个是状态机的入口,以api_next_state为判断依据,第二个以next_state为依据。此时next_state是HttpTransact::SERVE_FROM_CACHE,执行了HttpSM::setup_cache_read_transfer函数,函数中设置了状态机的回调函数为HttpSM::tunnel_handler。之后一直执行,会执行write_to_net函数,并触发HttpSM::tunnel_handler函数。HttpSM::tunnel_handler函数执行会间接的执行到HttpSM::kill_this函数,函数中将t_state.api_next_action设置为最后一个state,HttpTransact::HTTP_API_SM_SHUTDOWN。

第八个state是HttpTransact::HTTP_API_SM_SHUTDOWN,执行清理操作,直接结束

时间: 2024-10-17 01:37:16

ATS请求处理状态机流程(缓存命中)的相关文章

缓存命中

缓存命中率 终端用户访问加速节点时,如果该节点有缓存住了要被访问的数据时就叫做命中,如果没有的话需要回原服务器取,就是没有命中.取数据的过程与用户访问是同步进行的,所以即使是重新取的新数据,用户也不会感觉到有延时. 命中率=命中数/(命中数+没有命中数), 缓存命中率是判断加速效果好坏的重要因素之一. 缓存命中:是从缓存中能够获取需要的数据就叫命中 不命中:没有从缓存中获取想要的数据,需要再次查询数据库或者执行其他操作,可能的原因是缓存中没有该数据或者缓存过期

缓存命中和性能的关系论证

<性能之巅>中关于性能和缓存部分,有两点在读到是有一些困惑,做以下思考. 1. 为什么99%的缓存命中,和98%的缓存命中,两者性能差距,远大于11%和10%的差距 具体的论证仔细思考了一下,可以推导如下: 现做以下变量定义: k:命中率,[0,1]之间 t:没有命中的处理耗时,[1,max],此处假设命中后的处理时间是1,此处假定命中和不命中的处理速度为固定倍数差异. A:总的任务量 T:总的开销时间 于是有以下公式: T = A * k *  1 + A * (1-k)* t 进行推导,就

ATS读大文件(命中)

大文件存储结构和小文件完全不同,小文件占一个fragment就够了,小文件占若干个fragment.小文件第一个是doc只存一些信息数据,包括http头,资源的content存在于若干个fragment中,默认每个fragment展1048576字节,在proxy.config.cache.target_fragment_size中可以改.一个fragment中有72个字节是doc,剩下的是资源的content.ats会先读第一个fragment,然后以循环的方式读取若干个fragment,直到

ATS读小文件(内存命中)

一个资源根据其大小可能会存在多个存储对象中.如果足够小(连同doc结构的大小小于一个fragment的size),连同这个资源的meta信息一起存储在一个doc中.如果比较大,第一个存储对象保存资源的meta信息,后面跟着若干个fragment存着资源的content.这里讨论小文件读行为,并且内存命中,在资源第二次命中的时候才有可能是内存命中.整个流程在主状态机流程的入口函数是Cache::open_read,正流程如下: Cache::open_read: 计算的到vol.运行了dir_pr

缓存服务器-varnish

Varnish 简介 Varnish是一款高性能且开源的反向代理服务器和 HTTP 加速器(其实就是带缓存的反向代理服务),它可以把整个HTTP响应内容缓存到内存或文件中,从而提高Web服务器的响应速度.其采用全新的软件体系机构,和现在的硬件体系紧密配合,与传统的 squid 相比,varnish 具有性能更高.速度更快.管理更加方便等诸多优点,很多大型的网站都开始尝试使用 varnish 来替换 squid,这些都促进 varnish 迅速发展起来. Varnish内置强大的VCL(Varni

Varnish缓存代理简介与配置

一.varnish原理: 1)Varnish简介: varnish缓存是web应用加速器,同时也作为http反向缓存代理.你可以安装varnish在任何http的前端,同时配置它缓存内容.与传统的 squid 相比,varnish 具有性能更高.速度更快.管理更加方便等诸多优点.有一部分企业已经在生产环境中使用其作为旧版本的squid的替代方案,以在相同的服务器成本下提供更好的缓存效果,Varnish更是作为CDN缓存服务器的可选服务之一. 根据官网的介绍,Varnish的主要特性如下:http

varnish 4.0 缓存代理配置

一.varnish原理: 1)Varnish简介: varnish缓存是web应用加速器,同时也作为http反向缓存代理.你可以安装varnish在任何http的前端,同时配置它缓存内容.与传统的 squid 相比,varnish 具有性能更高.速度更快.管理更加方便等诸多优点.有一部分企业已经在生产环境中使用其作为旧版本的squid的替代方案,以在相同的服务器成本下提供更好的缓存效果,Varnish更是作为CDN缓存服务器的可选服务之一. 根据官网的介绍,Varnish的主要特性如下:http

varnish缓存服务

缓存的基础知识1.程序本身具有局部性时间局部性 过去访问到的数据,也有可能被两次访问 空间局部性 一个数据被访问到时,离它最近的文件可能马上也会被访问 2.命中率文档命中率 从文档个数进行衡量 字节命中率 从内容大小进行衡量 3.缓存系统的特性缓存对象 有生命周期,且是定期清理的 缓存空间耗尽 使用LRU(最近最少使用算法)或者MRU算法进行缓存项清理 不可缓存项 用户私有数据 4.缓存系统一般处理步骤接收请求解析请求 提取请求的URL及各种首部 查询缓存新鲜度检测创建响应报文发送响应报文记录日

varnish4.0缓存代理配置

防伪码:你必须非常努力,才能看起来毫不费力. 一.varnish原理: 1)Varnish简介: varnish缓存是web应用加速器,同时也作为http反向缓存代理.你可以安装varnish在任何http的前端,同时配置它缓存内容.与传统的 squid 相比,varnish 具有性能更高.速度更快.管理更加方便等诸多优点.有一部分企业已经在生产环境中使用其作为旧版本的squid的替代方案,以在相同的服务器成本下提供更好的缓存效果,Varnish更是作为CDN缓存服务器的可选服务之一. 根据官网