但后来发现都有问题。前者处理在实际中几乎没什么用处,而且session回收还得自己另外处理。后者频繁的操作数据库,打来了很大的性能问题。
这两天仔细考虑下,大致给出一个方案,但还没有具体详细的测试。
1、session处理和统计结合起来。同时游客也都有记录。
2、完全使用数据库和cookie来模拟session的功能。
3、用户的对session的操作都尽量保证在一条sql语句完成。不用到session的时候,绝对不多一条查询。
4、为了效率起见,session的回收没有集成进来,但提供了接口,可以调用实现。
暂时给出代码,不具体解释。
sql
CREATE TABLE `*****_session` (
`sid` char(32) NOT NULL,
`uid` int(10) NOT NULL,
`username` char(32) NOT NULL,
`usertype` tinyint(1) NOT NULL,
`activetime` int(10) NOT NULL,
`expiry` int(10) NOT NULL,
`ip` char(15) NOT NULL,
`url` char(80) NOT NULL,
`value` char(255) NOT NULL,
PRIMARY KEY (`sid`)
) ENGINE=MEMORY DEFAULT CHARSET=utf8;
php代码
<?
class session{
private $_sessionPrex= '';//session的前缀
private $_time = '';//当前时间
private $_model = null;//数据库操作模型
private $_expiry = 1200;//session有效时间
private $_domain = '';//session的作用域
protected $isNew = 0;//判定操作动作 0 更新 1 增加
protected $session = array();//对应的一条session记录
public function __construct($options){
$this->_setOptions($options);
if(empty($this->_time))$this->_time = time();
$this->session['activetime'] = $this->_time;
}
public function start(){
$this->_getSid();
}
public function set($key,$value){
if(in_array($key,array('uid','username','usertype','url','expiry'))){
if($key == 'expiry'){
$this->_setCookie($this->_sessionPrex.'_sid',$this->session['sid'],$value);
$this->_setCookie($this->_sessionPrex.'_uid',$this->session['uid'],$value);
}
$this->session[$key] = $value;
}else{
$other = $this->session['value'];
$other[$key] = $value;
$this->session['value'] = $other;
}
}
public function get($key){
if(in_array($key,array('uid','username','usertype','url','expiry'))){
return $this->session[$key];
}else{
if(isset($this->session['value'][$key])){
return $this->session['value'][$key];
}
return null;
}
}
public function gc($file,$time = 1200){
$lasttime = file_get_contents($file);
if($lasttime + $time<$this->_time){
file_put_contents($file,$this->_time);
return $this->_model->delete('activetime+expiry<'.$this->_time);
}
}
public function destroy(){
$this->session['uid'] = 0;
$this->session['username'] = '';
$this->session['usertype'] = -1;
$this->session['expiry'] = $this->_expiry;
$this->session['value'] = array();
$this->_setCookie($this->_sessionPrex.'_sid',$this->session['sid'],$this->_expiry);
$this->_setCookie($this->_sessionPrex.'_uid',$this->session['uid'],$this->_expiry);
}
public function __destruct(){
$this->_save();
}
private function _save(){
$dbSession = $this->session;
$dbSession['value'] = serialize($dbSession['value']);
if(strlen($dbSession['value'])>255)$this->_error('session->value is too long!');
if($this->isNew == 1){
//增加
$this->_model->insert($dbSession);
}else{
//更新
$sid = $dbSession['sid'];
$this->_model->update(array_slice($dbSession,1),'sid=\''.$sid.'\'');
}
}
private function _getSession($sid){
$dbSession = $this->_model->detail('sid = \''.$sid.'\'');
if(!$dbSession)return false;
$dbSession['value'] = unserialize($dbSession['value']);
$this->session = array_merge($dbSession,$this->session);
return true;
}
private function _getSid(){
$sid = strip_tags($_COOKIE[$this->_sessionPrex.'_sid']);
if(strlen($sid)==32){
if($this->_getSession($sid)){
return true;
}
}else{
$sid = md5(time().mt_rand(1000,10000));
$this->_setCookie($this->_sessionPrex.'_sid',$sid);
}
$this->_setCookie($this->_sessionPrex.'_uid',0);
$this->session = array(
'uid' => 0,
'username' => '',
'usertype' => -1,
'activetime' => $this->_time,
'ip' => $this->_getip(),
'url' => strip_tags($_SERVER['REQUEST_URI']),
'expiry' =>$this->_expiry,
'value' => array()
);
$this->isNew = 1;
$this->session['sid'] = $sid;
}
private function _setCookie($name,$value,$expiry=0){
if(empty($expiry))$expiry = $this->_expiry;
if(empty($this->_domain)){
setcookie($name,$value,$this->_time + $expiry,'/');
}else{
setcookie($name,$value,$this->_time + $expiry,'/',$this->_domain);
}
}
private function _getip(){
return getip();
}
private function _setOptions($options){
foreach ($options as $key=>$value){
if(in_array($key,array('sessionPrex','time','model','expiry','domain'))){
$key = '_'.$key;
$this->$key = $value;
}
}
}
private function _error($msg){
throw new Phpbean_Exception($msg);
}
}
?>
(注意,该代码不能直接使用,本文主要是提供一种思路)
在 Blog 盛行的今天,一些 Web 应用需要解析大量的 RSS Feed .如何提高效率是个非常重要的问题.在 MagpieRSS 的 Features 中列举了这样的一条: HTTP Conditional GETs Save bandwidth and speed up download times with intelligent use of Last-Modified and ETag.. 这里的 Etag 引起了我的注意.
什么是 Etag ?
通过阅读 RFC 2616 ,得到了对 Etag 的一点印象:
The ETag response-header field provides the current value of the entity tag for the requested variant......Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.从上我们可以大致得知,Entity tags 本质上说是一种"强校验器",但是 HTTP 协议提供了一种通过给 Entity tags 打标签的"弱"的机制(类似于内容的校验码).虽然这段话后面通过两种方式进行了解释,但是还是有些晦涩.我看了这段话之后只是得出了 Etag 的 "E" 代表 "Entity" 而已.
Magpie 首页上提到了一篇文章: HTTP Conditional Get for RSS Hackers ,拜读之后清晰了许多.要先说说 HTTP Conditional GETs 的基本原理,很简单,就是说,从 Web 服务器取数据的时候,如果文件变化了,给我新的文件,如果文件没有变化,只需告诉客户端没有变化即可,不必再把文件取回来.这样就可节省大量的网络带宽和资源.
Etag 与 Last-Modified 是从 HTTP 1.0 到 HTTP 1.1 才有的概念.当我们从 Web 服务器获取文件的时候,只需要读取 HTTP 响应头的 Etag 与 Last-Modified 字段即可,这两个字段里面的具体内容是什么可以不管(可能会千奇百怪,RFC 2616 对 Etag 没有具体值的定义),把这两个值 Cache 在本地,下次检查文件是否更新的时候比对这两个值即可.如果没有变化,服务器的响应代码不是 HTTP 200 (OK) , 而是 304.
如上图.目前 OpenRSS 虽然订阅了40 多个 Feed,但是响应速度很不错.在使用 Gregarius 的过程中(Lilina 也应用了 ETag),发现了 FeedBurnrer 烧录的 Feed ,几乎都是用了 Etag 的(否则估计服务器要瘫痪,Hoho).我们再测试一下 HTTP header 的响应情况:
$ curl -I http://feeds.feedburner.com/dbanotes HTTP/1.1 200 OK Date: Tue, 25 Oct 2005 11:34:15 GMT Server: Apache Last-Modified: Tue, 25 Oct 2005 04:30:12 GMT ETag: U4q478bDKLqZ8UMMC8A5afZuHug Content-Type: text/xml;charset=utf-8 $ curl -I http://feeds.feedburner.com/dbanotes HTTP/1.1 200 OK Date: Tue, 25 Oct 2005 11:34:21 GMT Server: Apache Last-Modified: Tue, 25 Oct 2005 04:30:12 GMT ETag: U4q478bDKLqZ8UMMC8A5afZuHug Content-Type: text/xml;charset=utf-8
在这个期间,我的 Blog 没有更新.所以 Last-Modified 和 ETag 返回的都是相同的值.这样 Gregarius 就不必重新解析了. 国内的 GreatNews 是支持 HTTP Conditional GETs 的,更棒的是还支持 gzip/deflate encoding.而另一个 RSS 阅读工具 POPU (周博通) 就不知道了.
以上是我的笔记,如有理解错误,请指正!
最近,大众对于REST风格应用架构表现出强烈兴趣,这表明Web的优雅设计开始受到人们的注意。现在,我们逐渐理解了“3W架构(Architecture of the World Wide Web)”内在所蕴含的可伸缩性和弹性,并进一步探索运用其范式的方法。本文中,我们将探究一个可被Web开发者利用的、鲜为人知的工具,不引人注意的“ETag响应头(ETag Response Header)”,以及如何将它集成进基于Spring和Hibernate的动态Web应用,以提升应用程序性能和可伸缩性。
我们将要使用的Spring框架应用是基于“宠物诊所(petclinic)”的。下载文件中包含了关于如何增加必要的配置及源码的说明,你可以自己尝试。
什么是“ETag”?HTTP协议规格说明定义ETag为“被请求变量的实体值” (参见 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html —— 章节 14.19)。 另一种说法是,ETag是一个可以与Web资源关联的记号(token)。典型的Web资源可以一个Web页,但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义,并在HTTP响应头中将其传送到客户端。
ETag如何帮助提升性能?聪明的服务器开发者会把ETags和GET请求的“If-None-Match”头一起使用,这样可利用客户端(例如浏览器)的缓存。因为服务器首先产生ETag,服务器可在稍后使用它来判断页面是否已经被修改。本质上,客户端通过将该记号传回服务器要求服务器验证其(客户端)缓存。
其过程如下:
本文的其余部分将展示在基于Spring框架的Web应用中利用ETag的两种方法,该应用使用Spring MVC。首先我们将使用Servlet 2.3 Filter,利用展现视图(rendered view)的MD5校验和(checksum)以实现生成ETag的方法(一个“浅显的”ETag实现)。 第二种方法使用更为复杂的方法追踪view中所使用的model,以确定ETag有效性(一个“深入的”ETag实现)。尽管我们使用的是Spring MVC,但该技术可以应用于任何MVC风格的Web框架。
在我们继续之前,强调一下这里所展现的是提升动态产生页面性能的技术。已有的优化技术也应作为整体优化和应用性能特性调整分析的一部分来考虑。(见下)。
自顶向下的Web缓存
本文主要涉及对动态生成页面使用HTTP缓存技术。当考虑提升Web应用的性能的时候,应采取一个整体的、自顶向下的方法。为了这一目的,理解HTTP请求经过的各层是很重要的,应用哪些适当的技术取决于你所关注的热点。例如:
- 将Apache作为Servlet容器的前端,来处理如图片和javascript脚本这样的静态文件,而且还可以使用FileETag指令创建ETag响应头。
- 使用针对javascript文件的优化技术,如将多个文件合并到一个文件中以及压缩空格。
- 利用GZip和缓存控制头(Cache-Control headers)。
- 为确定你的Spring框架应用的痛处所在,可以考虑使用 JamonPerformanceMonitorInterceptor。
- 确信你充分利用ORM工具的缓存机制,因此对象不需要从数据库中频繁的再生。花时间确定如何让查询缓存为你工作是值得的。
- 确保你最小化数据库中获取的数据量,尤其是大的列表。如果每个页面只请求大列表的一个小子集,那么大列表的数据应由其中某个页面一次获得。
- 使放入到HTTP session中的数据量最小。这样内存得到释放,而且当将应用集群的时候也会有所帮助。
- 使用数据库明细(database profiling)工具来查看在查询的时候使用了什么索引,在更新的时候整个表没有被上锁。
当然,应用性能优化的至理名言是:两次测量,一次剪裁(measure twice, cut once)。哦,等等,这是对木工而言的!没错,但是它在这里也很适用!
ETag Filter内容体我们要考虑的第一种方法是创建一个Servlet Filter,它将基于页面(MVC中的“View”)的内容产生其ETag 记号。乍一看,使用这种方法所获得的任何性能提升看起来都是违反直觉的。我们仍然不得不产生页面,而且还增加了产生记号的计算时间。然而,这里的想法是减少带宽使用。在大的响应时间情形下,如你的主机和客户端分布在这个星球的两端,这很大程度上是有益的。我曾见过东京办公室使用纽约服务器上托管的应用,其响应时间达到了 350 ms。随着并发用户数的增长,这将变成巨大的瓶颈。
代码我们用来产生记号的技术是基于从页面内容计算MD5哈希值。这通过在响应之上创建一个包装器来实现。该包装器使用字节数组来保存所产生的内容,在filter链处理完成之后我们利用数组的MD5哈希值计算记号。
doFilter方法的实现如下所示。
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException,
ServletException {
HttpServletRequest servletRequest = (HttpServletRequest) req;
HttpServletResponse servletResponse = (HttpServletResponse) res;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ETagResponseWrapper wrappedResponse = new ETagResponseWrapper(servletResponse, baos);
chain.doFilter(servletRequest, wrappedResponse);
byte[] bytes = baos.toByteArray();
String token = '"' + ETagComputeUtils.getMd5Digest(bytes) + '"';
servletResponse.setHeader("ETag", token); // always store the ETag in the header
String previousToken = servletRequest.getHeader("If-None-Match");
if (previousToken != null && previousToken.equals(token)) { // compare previous token with current one
logger.debug("ETag match: returning 304 Not Modified");
servletResponse.sendError(HttpServletResponse.SC_NOT_MODIFIED);
// use the same date we sent when we created the ETag the first time through
servletResponse.setHeader("Last-Modified", servletRequest.getHeader("If-Modified-Since"));
} else { // first time through - set last modified time to now
Calendar cal = Calendar.getInstance();
cal.set(Calendar.MILLISECOND, 0);
Date lastModified = cal.getTime();
servletResponse.setDateHeader("Last-Modified", lastModified.getTime());
logger.debug("Writing body content");
servletResponse.setContentLength(bytes.length);
ServletOutputStream sos = servletResponse.getOutputStream();
sos.write(bytes);
sos.flush();
sos.close();
}
}