SmartGov3.5版——基于缓存队列的在线访谈性能改进实现
在SmartGov3.0发布后,我们就一直在想办法把在线访谈文字直播所支持的并发性和负载能力至少增加1倍以上,开发部经过一个多月的努力,完成了对线访谈文字直播部分的优化。我们总结了优化的过程分享给可能遇到相同问题的朋友做为参考,非常欢迎大家指出我们的不足,我们会继续加以改进。
基于在线访谈对高实时性、大并发性和高负载性的需求,我们针对在线访谈模块分别在多级缓存与缓存的可扩展性、网络带宽的节省、多客户端支持和代码执行性能等方面进行了改进。
首先我们来看一下改进前后的部署结构图
改进前部署图
在对在线访谈部分改进之前,访谈用户的写入时直接存放到数据库中,而读取是通过一个缓存的List列表完成。当访谈开始的时候,后台管理员录入访谈内容,写入数据库,然后更新整个List列表。对于前台文字直播页面,首先由DetialList.aspx页去请求直播内容,DetailList.aspx根据情况是去选择读取数据库还是直接返回List缓存列表。从改进前的请求流程来看,存在着以下问题:
1、添加访谈内容时,会更新整个List列表,而更新整个List列表会读取数据库,并且经过监测发现前台读取缓存List时缓存命中率也比较低。
2、目前的SmartGov的在线直播是直接采用HttpRuntim.Cache,而不能够在发布后更改成其他缓存方式。
3、直接采用的是DetialList.aspx页面来显示直播内容,而作为前台动态页,每次请求的输出会经过模板绑定、解析、其他多余的HTML代码、页面事件等流程。
基于以上问题,我们对在线访谈做多重改进来解决潜在的瓶颈。首先看一下改进后的部署结构图:
改进后部署图
从两个结构图的对比来看,改进后的部署结构的复杂性、扩展性有了一个层次的提高。在新的结构下,部署改进了如下内容:
1、可支持独立的缓存服务器。新的结构图下,我们既可以沿用原有的部署方式,从而节省硬件的开支。当系统需要支持高负载、高并发的运行环境时,就可以根据所承担的负载性进行扩展部署,更换缓存接口,实现独立的缓存服务器(可以通过自己实现我们提供的缓存接口或者定制来满足要求)。缓存部分可以采用Memcached等其他分布式缓存来代替原来的HttpRuntim.Cache。
2、在代码方面,我们优化了代码的执行性能,并且增加了缓存队列来代替原来的List列表缓存方式。这样在更新缓存内容时,只更新最新的数据,而不用重新获取整个List列表。这样大大的提高了缓存命中率,我们检测发现文字直播读取时几乎不会读取数据库,所有的内容都在缓存队列中。
3、通过直接调用DetialList.aspx来显示访谈记录改变成了WebServices的方式,这样既可以把WebServices来做二级缓存,也可以用来支持多客户端、多应用程序直播的方式。采用WebServices减少了aspx页面事件和模板绑定流程,从而会大大减少页面的请求的时间,更快的反馈给用户请求结果;采用WebServices减少了页面大小,降低了对带宽的需求和节省流量。
a) 对于改进前后我们还使用了测试工具对它们的性能进行了一次测试比较。在没有改进之前,一次页面请求大概需要消耗86毫秒的时间,但改进后一次web服务的请求,大概需要消耗22毫秒的时间。从数据上来看,性能几乎提升了3倍多。
以下为测试请求DetailList.aspx页面执行Page_Load方法的截图:
改进前性能测试
b) 请求DetailListService web服务的截图
改进后性能测试
4、节省服务器带宽,降低应用单位的流量费用。对于访谈数据是采用.NET webservice的方式进行调用。使用这种方式,数据将可以用Json格式或xml格式进行传输,相比每次请求的都返回整个HTML格式的页面数据来看,每次的请求流量比原来页面方式降低了4倍。
a) 使用firebug来测试页面的加载流量,下图是改进前传输到客户端的数据为8kb
改进前的请求大小比较
b) 改进后请求返回的数据仅为2KB
改进后的请求大小比较
从上面的数据来对比看,内容直接压缩了4倍左右。返回的数据少,当然加载也就快了。
用户登录
还没有账号?
立即注册