fastcgi工作方式引起的问题
环境:debian + fastcgi + nginx + django + sqlachemy +mysql问题:在页面中使用ajax发起删除操作之后,再另一个发起查询,查询出来的是删除之前的数据.
同事猜测:html缓存/我觉得不是html的缓存,而是fastcgi处理方法引起的.(在另一篇我会说说django页面处理.)
ajax代码:
/* url="/conf/del_warnlog_rt_ajax/"
* dic= { "key":"value" }
*/
function deal_ajax( url, dic ){
$.post( url, dic, function( data ){
get_app_table_2();//更新页面table表的数据
})
}
如果去掉nginx+fastcgi的话,直接:
python manage.py runserver 0.0.0.0:8966
运行的话,不会出现前面的问题.
对比这个2种情况:可以隐约知道是fastcgi在做好事情:
1.直接运行django的话:web服务器处理方式方法:先请求第一个url,之后再运行get_app_table_2()---瞎猜的,至少程序表现就是如此.
2.而运行fastcgi的话:web服务器(准确的说是nginx+fastcgi+django)表现是处理了第一个url请求,(一次有可能要删除好几十条记录),在这个删除还没有完成,就返回给用户了,页面立即发起另一个请求: get_app_table_2(),结果页面显示出来的是删除失败!实际上查看mysql,删除以及完成,之后点击翻页也表现出数据库的改变.翻页也是调用get_app_table_2()这个函数的完成请求,可见页面不是因为缓存引起的问题.(Fastcgi到底是什么样的技术里面可能能够解释这个现象!)
----------------------------------------------Fastcgi到底是什么样的技术-----------------------------------------------
从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与(注1)
----------------------------------------------------------------------------------------------------------------------------------
经过以上分析:我觉得对常规处理函数deal_ajax进行针对性改进:
get_app_table_2()-->setTimeout( "get_app_table_2()", 500 );
延时调用下一个url请求:
结果:运行fastcgi验证,表现正常.
页:
[1]