月度归档:2009 年一月

在PHP里利用魔术方法实现准AOP

在传统的OOP(面向对象编程:Object-Oriented Programming)思想里,一般把应用程序分解成若干个的对象,强调高内聚,弱耦合,从而提高应用程序的模块化程度,但是在处理某些问题的时 候,OOP会显得不够灵活,比如说,应用程序里很多业务逻辑都要在操作之初进行“权限检查”,在操作之后进行“日志记录”,如果直接把处理这些操作的代码 加入到每个模块中,那么无疑破坏了OOP的“单一职责”原则,模块的可重用性会大大降低,这时候传统的OOP设计往往采取的策略是加入相应的代理 (Proxy)层来完成系统的功能要求,但这样的处理明显使系统整体增加了一个层次的划分,复杂性也随之增加,从而给人过于厚重的感觉。正是为了处理这样 的问题,AOP(面向方面编程:Aspect-Oriented Programming)思想应运而生了,假设把应用程序想成一个立体结构的话,OOP的利刃是纵向切入系统,把系统划分为很多个模块(如:用户模块,文 章模块等等),而AOP的利刃是横向切入系统,提取各个模块可能都要重复操作的部分(如:权限检查,日志记录等等)。由此可见,AOP是OOP的一个有效 补充。

就目前的PHP来说,还没有一个完整的AOP内置实现,虽然出现了RunKit, 但一直都以BETA的状态呆在PECL项目里,估计很长时间内不太可能成为PHP的缺省设置。那是不是AOP在PHP里就破灭了呢?当然不是,因为我们有 __get(),__set(),__call()等魔术方法,合理使用这些方法可以为我们实现某种程度的“准AOP”能力,之所以说是准AOP,是因为 单单从实现上来看,称其为AOP有些牵强,但是从效果上来看,又部分实现了AOP的作用,虽然其实现方式并不完美,但对于一般的使用已经足够了。特别是从 PHP4.3.0开始,这些魔术方法已经成为了PHP的缺省内置实现,扫除了PHP4/5兼容的顾虑,那么就更加没有理由不使用它们。这里要说明的是 PHP4/5对这些魔术方法的实现有些许的不同,下面将分别举例说明:

先来看看PHP4的相应代码(下面代码只能运行在PHP4环境下):

<?php
//应用程序中某个业务逻辑类
class
BIZ
{
function
foobar
()
{
echo
‘业务逻辑<br />’
;
}
}

//业务逻辑类的包装类
class
AOP
{
var
$instance
;

function AOP($instance)
{
$this->instance = $instance
;
}

function __call($method, $argument, $return)
{
if(!
method_exists($this->instance, $method
))
{
return
false
;
}

echo ‘权限检查<br />’;

$callBack = array($this->instance, $method);

$return = call_user_func_array($callBack, $argument);

echo ‘日志记录<br />’;

return true;
}
}

//工厂方法
class
Factory
{
function
getBizInstance
()
{
//PHP4必须这样声明一下才可以使用overload相关方法
overload(‘AOP’
);

return new AOP(new BIZ());
}
}

//客户端调用演示
header(“Content-Type: text/html; charset=gbk”
);

$obj = Factory::getBizInstance();

$obj->foobar();
?>

屏幕显示:

权限检查
业务逻辑
日志记录

再来看看PHP5的相应代码(下面代码只能运行在PHP5的环境下):

<?php
//应用程序中某个业务逻辑类
class BIZ
{
public function
foobar()
{
echo
‘业务逻辑<br />’;
}
}

//业务逻辑类的包装类
class AOP
{
private
$instance;

public function __construct($instance)
{
$this->instance = $instance;
}

public function __call($method, $argument)
{
if(!
method_exists($this->instance, $method))
{
throw new
Exception(‘未定义的方法:’ . $method);
}

echo ‘权限检查<br />’;

$callBack = array($this->instance, $method);

$return = call_user_func_array($callBack, $argument);

echo ‘日志记录<br />’;

return $return;
}
}

//工厂方法
class Factory
{
public function
getBizInstance()
{
return new
AOP(new BIZ());
}
}

//客户端调用演示
header(“Content-Type: text/html; charset=gbk”);

try
{
$obj = Factory::getBizInstance();

$obj->foobar();
}
catch(
Exception $e)
{
echo
‘Caught exception: ’, $e->getMessage();
}
?>

屏幕显示:

权限检查
业务逻辑
日志记录

总结:

代 码中的粗体部分是表示PHP4/5有差异的地方,具体解释可以参考手册。整个的实现思路其实很简单,关键就是客户端请求的对象不能直接实例化出来,而是利 用工厂方法返回一个请求对象的包装对象,在包装对象内利用魔术方法来处理权限处理,日志记录等公共操作。这既是巧妙的地方,也是最有可能出问题的地方,因 为客户端使用对象并不是它想象中的对象,而是一个包装后的对象,比如说,客户端通过getBizInstance()方法以为得到的对象是BIZ,但实际 上它得到的是一个BIZ的包装对象AOP,这样的话,如果客户端进行一些诸如get_class()之类和对象类型相关的操作就会出错,当然,大多数情况 下,客户端似乎不太会做类似的操作,末了,再唠叨几句,为了脚本在PHP4/5都能运行,可以分别用两个脚本实现AOP类,然后用 version_compare()方法来决定加载哪一个。

Php魔术函数学习与应用

(1)初识魔术方法
Php5.0发布以来为我们提供了很多面向对象的特性,尤其是为我们提供了好多易用的魔术方法,这些魔术方法可以让我们简化我们的编码,更好的设计我们的系统。今天我们就来认识下php5.0给我们提供的魔术方法。

1,__construct() 当实例化一个对象的时候,这个对象的这个方法首先被调用。
class Test
{
function __construct()

{
echo “before”;
}
}

$t = new Test();

输出是:

start
我们知道php5对象模型 和类名相同的函数是类的构造函数,那么如果我们同时定义构造函数和__construct()方法的话,php5会默认调用构造函数而不会调用__construct()函数,所以__construct()作为类的默认的构造函数

2,__destruct() 当删除一个对象或对象操作终止的时候,调用该方法。
class Test
{
function __destruct()
{
echo “end”;
}
}
$t = new Test();
将会输出
end

我们就可以在对象操作结束的时候进行释放资源之类的操作

3,__get() 当试图读取一个并不存在的属性的时候被调用。
如果试图读取一个对象并不存在的属性的时候,PHP就会给出错误信息。如果在类里添加__get方法,并且我们可以用这个函数实现类似java中反射的各种操作。
class Test
{
public function __get($key)
{
echo $key . ” 不存在”;
}
}

$t = new Test();
echo $t->name;

就会输出:
name 不存在

4,__set() 当试图向一个并不存在的属性写入值的时候被调用。
class Test
{
public function __set($key,$value)
{
echo ‘对’.$key . “附值”.$value;
}
}

$t = new Test();
$t->name = “aninggo”;

就会输出:
对 name 附值 aninggo

5,__call() 当试图调用一个对象并不存在的方法时,调用该方法。
class Test
{
public function __call($Key, $Args)
{
echo “您要调用的 {$Key} 方法不存在。你传入的参数是:” . print_r($Args, true);
}
}

$t = new Test();
$t->getName(aning,go);

程序将会输出:
您要调用的 getName 方法不存在。参数是:Array
(
[0] => aning
[1] => go
)

6,__toString() 当打印一个对象的时候被调用
这个方法类似于java的toString方法,当我们直接打印对象的时候回调用这个函数
class Test
{
public function __toString()
{
return “打印 Test”;
}
}

$t = new Test();

echo $t;

运行echo $t;的时候,就会调用$t->__toString();从而输出
打印 Test

7,__clone() 当对象被克隆时,被调用
class Test
{

public function __clone()
{
echo “我被复制了!”;
}
}

$t = new Test();
$t1 = clone $t;

程序输出:
我被克隆了!

8.顺便介绍下php5中提供的几个非常COOl的实验性函数
(1)。runkit_method_rename
这个函数可以动态的改变我们所调用的函数的名字。
class Test
{

function foo() {
return “foo! “;
}

}

runkit_method_rename(
‘Test’, //类名
‘foo’,//实际调用的函数
‘bar’//显示调用的函数
);

echo Test::bar();

程序将输出

foo!

(2) runkit_method_add

这个函数可以动态的向类中添加函数
class Test
{

function foo() {
return “foo! “;
}

}

runkit_method_add(
Test,  //类名
‘add’, //新函数名
‘$num1, $num2′,//传入参数
‘return $num1 + $num2;’,//执行的代码
RUNKIT_ACC_PUBLIC
);

// 调用
echo $e->add(12, 4);

(3)runkit_method_copy
可以把A类中的函数拷贝到类B中并对函数重命名
class Foo {
function example() {
return “foo! “;
}
}

class Bar {
//空类
}

//执行拷贝
runkit_method_copy(‘Bar’, ‘baz’, ‘Foo’, ‘example’);

//执行拷贝后的函数
echo Bar::baz();

(4) runkit_method_redefine
动态的修改函数的返回值
这个函数可以让我们轻松的实现对类的MOCK测试!是不是很COOL呢
class Example {
function foo() {
return “foo! “;
}
}

//创建一个测试对象
$e = new Example();

// 在测试对象之前输出
echo “Before: ” . $e->foo();

// 修改返回值
runkit_method_redefine(
‘Example’,
‘foo’,
”,
‘return “bar! “;’,
RUNKIT_ACC_PUBLIC
);

// 执行输出
echo “After: ” . $e->foo();

(5)runkit_method_remove
这个函数就很简单了,看名字就能看出来了,动态的从类中移除函数
class Test {
function foo() {
return “foo! “;
}

function bar() {
return “bar! “;
}
}

// 移除foo函数
runkit_method_remove(
‘Test’,
‘foo’
);

echo implode(‘ ‘, get_class_methods(‘Test’));

程序输出
bar

大型网站架构不得不考虑的10个问题

2009.01.15  来自:51CTO

这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依 靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构。这个时候,就需要 一个好的数据并发处理策略以及缓存策略。5、数据索引的问题。们这里不讨论是PHP还是JSP或者.NET环境,我们从架构的方面去看问题,实现语言方面 并不是问题,语言的优势在于实现而不是好坏,不论你选择任何语言,架构都是必须要面对的。

http://z.csdn.net/gmlog.php?bannerid=3039&clientid=991&zf=&zoneid=13&source=&block=0&capping=0&cb=68d10e73aeb50b4e42a87c37f139db83

这 里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们 以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环境,我们从 架构的方面去看问题,实现语言方面并不是问题,语言的优势在于实现而不是好坏,不论你选择任何语言,架构都是必须要面对的。

这里讨论一下大型网站需要注意和考虑的问题

1、海量数据的处理

众所周知,对于一些相对小的站点来说,数据量并不是很大,selectupdate就可以解决我们面对的问题,本身负载量不是很大,最多再加几个 索引就可以搞定。对于大型网站,每天的数据量可能就上百万,如果一个设计不好的多对多关系,在前期是没有任何问题的,但是随着用户的增长,数据量会是几何 级的增长的。在这个时候我们对于一个表的selectupdate的时候(还不说多表联合查询)的成本的非常高的。

2、数据并发的处理

在一些时候,2.0CTO都有个尚方宝剑,就是缓存。对于缓存,在高并发高处理的时候也是个大问题。在整个应用程序下,缓存是全局共享的,然而在 我们进行修改的时候就,如果两个或者多个请求同时对缓存有更新的要求的情况下,应用程序会直接的死掉。这个时候,就需要一个好的数据并发处理策略以及缓存 策略。

另外,就是数据库的死锁问题,也许平时我们感觉不到,死锁在高并发的情况下的出现的概率是非常高的,磁盘缓存就是一个大问题。

3、文件存贮的问题

对于一些支持文件上传的2.0的站点,在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文 件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下,如果一块硬盘存贮了500G的琐碎文件,那么维护的时候和使用的时候磁盘的Io就是一个 巨大的问题,哪怕你的带宽足够,但是你的磁盘也未必响应过来。如果这个时候还涉及上传,磁盘很容易就over了。

也许用raid和专用存贮服务器能解决眼下的问题,但是还有个问题就是各地的访问问题,也许我们的服务器在北京,可能在云南或者新疆的访问速度如何解决?如果做分布式,那么我们的文件索引以及架构该如何规划。

所以我们不得不承认,文件存贮是个很不容易的问题

4、数据关系的处理

我们可以很容易的规划出一个符合第三范式的数据库,里面布满了多对多关系,还能用GUID来替换INDENTIFY COLUMN 但是,多对多关系充斥的2.0时代,第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。

5、数据索引的问题

众所周知,索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是,在高UPDATE的情况下,updatedelete付出的成本会高的无法想想,笔者遇到过一个情况,在更新一个聚焦索引的时候需要10分钟来完成,那么对于站点来说,这些基本上是不可忍受的。

索引和更新是一对天生的冤家,问题ADE这些是我们在做架构的时候不得不考虑的问题,并且也可能是花费时间最多的问题,

6、分布式处理

对于2.0网站由于其高互动性,CDN实现的效果基本上为0,内容是实时更新的,我们常规的处理。为了保证各地的访问速度,我们就需要面对一个绝大的问题,就是如何有效的实现数据同步和更新,实现各地服务器的实时通讯有是一个不得不需要考虑的问题。

7Ajax的利弊分析

成也AJAX,败也AJAXAJAX成为了主流趋势,突然发现基于XMLHTTPpostget是如此的容易。客户端get或者post 到服务器数据,服务器接到数据请求之后返回来,这是一个很正常的AJAX请求。但是在AJAX处理的时候,如果我们使用一个抓包工具的话,对数据返回和处 理是一目了然。对于一些计算量大的AJAX请求的话,我们可以构造一个发包机,很容易就可以把一个webserver干掉。

8、数据安全性的分析

对于HTTP协议来说,数据包都是明文传输的,也许我们可以说我们可以用加密啊,但是对于G问题来说的话,加密的过程就可能是明文了(比如我们知道 的QQ,可以很容易的判断他的加密,并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你,但是当你流量上来之 后,那么所谓的外挂,所谓的群发就会接踵而来(qq一开始的群发可见端倪)。也许我们可以很的意的说,我们可以采用更高级别的判断甚至HTTPS来实 现,注意,当你做这些处理的时候付出的将是海量的databaseio以及CPU的成本。对于一些群发,基本上是不可能的。笔者已经可以实现对于百度空 间和qq空间的群发了。大家愿意试试,实际上并不是很难。

9、数据同步和集群的处理的问题

当我们的一台databaseserver不堪重负的时候,这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题 了,数据基于网络传输根据数据库的设计的不同,数据延迟是很可怕的问题,也是不可避免的问题,这样的话,我们就需要通过另外的手段来保证在这延迟的几秒或 者更长的几分钟时间内,实现有效的交互。比如数据散列,分割,内容处理等等问题

10、数据共享的渠道以及OPENAPI趋势

Openapi已经成为一个不可避免的趋势,从googlefacebookmyspace到海内校内,都在考虑这个问题,它可以更有效的留住 用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台,数据开放平台就成为必不可少的途径了,而在开放的接口 的情况保证数据的安全性和性能,又是一个我们必须要认真思考的问题了。

优化网站性能 提高网站速度访问速度的14条实践

相信互联网已经越来越成为人们生活中不可或缺的一部分。ajax,flex等等富客户端的应用使得人们越加“幸福”地体验着许多原先只能在C/S实 现的功 能。比如Google机会已经把最基本的office应用都搬到了互联网上。当然便利的同时毫无疑问的也使页面的速度越来越慢。自己是做前端开发的,在性 能方面,根据yahoo的调查,后台只占5%,而前端高达95%之多,其中有88%的东西是可以优化的。

以上是一张web2.0页面的生命周期图。工程师很形象地讲它分成了“怀孕,出生,毕业,结婚”四个阶段。如果在我们点击网页链接的时候能够意识到 这个过程而不是简单的请求-响应的话,我们便可以挖掘出很多细节上可以提升性能的东西。今天听了淘宝小马哥的一个对yahoo开发团队对web性能研究的 一个讲座,感觉收获很大,想在blog上做个分享。

相信很多人都听过优化网站性能的14条规则。更多的信息可见developer.yahoo.com

1. 尽可能的减少 HTTP 的请求数 [content]
2. 使用 CDN(Content Delivery Network) [server]
3. 添加 Expires 头(或者 Cache-control ) [server]
4. Gzip 组件 [server]
5. 将 CSS 样式放在页面的上方 [css]
6. 将脚本移动到底部(包括内联的) [javascript]
7. 避免使用 CSS 中的 Expressions [css]
8. 将 JavaScript 和 CSS 独立成外部文件 [javascript] [css]
9. 减少 DNS 查询 [content]
10. 压缩 JavaScript 和 CSS (包括内联的) [javascript] [css]
11. 避免重定向 [server]
12. 移除重复的脚本 [javascript]
13. 配置实体标签(ETags) [css]
14. 使 AJAX 缓存

在firefox下有一个插件yslow,集成在firebug中,你可以用它很方便地来看看自己的网站在这几个方面的表现。

这是对用yslow对我的网站西风坊测评的结果,很遗憾,只有51分。呵呵。中国各大网站的分值都不高,刚测了一下,新浪和网易都是31分。然后yahoo(美国)的分值确实97分!可见yahoo在这方面作出的努力。从他们总结的这14条规则,已经现在又新增加的20个点来看,有很多细节我们真得是怎么都不会去想,有些做法甚至是有些“变态”了。

第一条、尽可能的减少 HTTP 的请求数Make Fewer HTTP Requests

http请求是要开销的,想办法减少请求数自然可以提高网页速度。常用的方法,合并css,js(将一个页面中的css和js文件分别合并)以及 Image maps和css sprites等。当然或许将css,js文件拆分多个是因为css结构,共用等方面的考虑。阿里巴巴中文站当时的做法是开发时依然分开开发,然后在后台 对js,css进行合并,这样对于浏览器来说依然是一个请求,但是开发时仍然能还原成多个,方便管理和重复引用。yahoo甚至建议将首页的css和js 直接写在页面文件里面,而不是外部引用。因为首页的访问量太大了,这么做也可以减少两个请求数。而事实上国内的很多门户都是这么做的。

而css sprites是指只用将页面上的背景图合并成一张,然后通过css的background-position属性定义不过的值来取他的背景。淘宝和阿里巴巴中文站目前都是这样做的。有兴趣的可以看下淘宝和阿里巴巴的背景图

http://www.csssprites.com/ 这是个工具网站,它可以自动将你上传的图片合并并给出对应的background-position坐标。并将结果以png和gif的格式输出。

第二条、使用CDN(内容分发网络): Use a Content Delivery Network

简单地讲,通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的 cache服务器内,通过DNS负载均衡的技术,判断用户来源就近访问cache服务器取得所需的内容,杭州的用户访问近杭州服务器上的内容,北京的访问 近北京服务器上的内容。这样可以有效减少数据在网络上传输的时间,提高速度。更详细地内容大家可以参考百度百科上对于CDN的解释。Yahoo!把静态内容分布到CDN减少了用户影响时间20%或更多。

CDN技术示意图:

CDN组网示意图:

第三条、 添加Expire/Cache-Control 头:Add an Expires Header

现在越来越多的图片,脚本,css,flash被嵌入到页面中,当我们访问他们的时候势必会做许多次的http请求。其实我们可以通过设置Expires header 来缓存这些文件。Expire其实就是通过header报文来指定特定类型的文件在览器中的缓存时间。大多数的图片,flash在发布后都是不需要经常修 改的,做了缓存以后这样浏览器以后就不需要再从服务器下载这些文件而是而直接从缓存中读取,这样再次访问页面的速度会大大加快。一个典型的HTTP 1.1协议返回的头信息:
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: “3e86-410-3596fbbc”
Content-Length: 1040
Content-Type: text/html

其中通过服务器端脚本设置Cache-Control和Expires可以完成。

如,在php中设置30天后过期:

<!--pHeader("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 30;
$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s"time() + $offset) . " GMT";
Header($ExpStr);-->

也可以通过配置服务器本身完成,这些偶就不是很清楚了,呵呵。想了解跟多的朋友可以参考http://www.web-caching.com/

据我了解,目前阿里巴巴中文站的Expires过期时间是30天。不过期间也有过问题,特别是对于脚本过期时间的设置还是应该仔细考虑下,不然相应的脚本功能更新后客户端可能要过很长一段时间才能“感知”到这样的变化。以前做[suggest项目] 的时候就遇到过这个问题。所以,哪些应该缓存,哪些不该缓存还是应该仔细斟酌一番。

第四条、启用Gzip压缩:Gzip Components

Gzip的思想就是把文件先在服务器端进行压缩,然后再传输。这样可以显著减少文件传输的大小。传输完毕后浏览器会 重新对压缩过的内容进行解压缩,并执行。目前的浏览器都能“良好”地支持 gzip。不仅浏览器可以识别,而且各大“爬虫”也同样可以识别,各位seoer可以放下心了。而且gzip的压缩比例非常大,一般压缩率为85%,就是 说服务器端100K的页面可以压缩到25K左右再发送到客户端。具体的Gzip压缩原理大家可以参考csdn上的《gzip压缩算法 这篇文章。雅虎特别强调, 所有的文本内容都应该被gzip压缩: html (php), js, css, xml, txt… 这一点我们网站做得不错,是一个A。以前我们的首页也并不是A,因为首页上还有很多广告代码投放的js,这些广告代码拥有者的网站的js没有经过gzip压缩,也会拖累我们网站。

以上三点大多属于服务器端的内容,本人也是粗浅地了解而已。说得不对的地方有待各位指正。

第五条、将css放在页面最上面 ( Put Stylesheets at the Top)

将css放在页面最上面,这是为什么?因为 ie,firefox等浏览器在css全部传输完全之前不会去渲染任何的东西。理由诚如小马哥说得那样很简单。css,全称Cascading Style Sheets (层叠样式表单)。层叠即意味这后面的css可以覆盖前面的css,级别高的css可以覆盖级别低的css。在[css之!important] 这篇文章的最下面曾简单地提到过这层级关系,这里我们只需要知道css可以被覆盖的。既然前面的可以被覆盖,浏览器在他完全加载完毕之后再去渲染无疑也是合情合理的很多浏览器下,如IE,把样式表放在页面的底部的问题在于它禁止了网页内容的顺序显示。浏览器阻止显示以免重画页面元素,那用户只能看到空白页了。Firefox不会阻止显示,但这意味着当样式表下载后,有些页面元素可能需要重画,这导致闪烁问题。所以我们应该尽快让css加载完毕

顺着这层意思,如果我们再细究的话,其实还有可以优化的地方。比如本站上面包含的两个css文件,<link rel=“stylesheet” rev=“stylesheet” href=“http://www.space007.com/themes/google/style/google.css” type=“text/css” media=“screen” /> 和<link rel=“stylesheet” rev=“stylesheet” href=“http://www.space007.com/css/print.css” type=“text/css” media=“print” />。 从media就可以看出第一个css是针对浏览器的,第二个css文件是针对打印样式的。从用户的行为习惯上来将,要打印页面的动作一定是发生在页面页面 显示出来之后的。所以比较好的方法应该是在页面加载完毕之后再动态地为这张页面加上针对打印设备的css,这样又可以提高一点速度。(哈哈)

第六条、将script放在页面最下面 (Put Scripts at the Bottom )

将脚本放在页面最下面的目的有那么两点: 1、 因为防止script脚本的执行阻塞页面的下载。在页面loading的过程中,当浏览器读到js执行语句的时候一定会把它全部解释完毕后在会接下来读下 面的内容。不信你可以写一个js死循环看看页面下面的东西还会不会出来。(setTimeout 和 setInterval的执行有点类似于多线程,在相应的响应时间之前也会继续下面的内容渲染。)浏览器这么做的逻辑是因为js随时可能执 行 location.href或是其他可能完全中断此页面过程的函数,即如此,当然得等他执行完毕之后再加载咯。所以放在页面最后,可以有效减少页面可 视元素的加载时间。        2、脚本引起的第二个问题是它阻塞并行下载数量。HTTP/1.1规范建议浏览器每个主机的并行下载数不超过2个(IE只能为2个,其他浏览器如ff等都是默认设置为2个,不过新出的ie8可以达6个)。因此如果您把图像文件分布到多台机器的话,您可以达到超过2个的并行下载。但是当脚本文件下载时,浏览器不会启动其他的并行下载。

当然对各个网站来说,把脚本都放到页面底部加载的可行性还是值得商榷的。就比如阿里巴巴中文站的页面。很多地方有内联的js,页面的显示严重依赖于此,我承认这和无侵入脚本的理念相差甚远,但是很多“历史遗留问题”却不是那么容易解决的。

第七条、避免在CSS中使用Expressions (Avoid CSS Expressions )

不过这样就多了两层无意义的嵌套,肯定不好。还需要一个更好的办法。

第八条、把javascript和css都放到外部文件中 (Make JavaScript and CSS External )

这点我想还是很容易理解的。不仅从性能优化上会这么做,用代码易于维护的角度看也应该这么做。把css和js写在页面内容可以减少2次请求,但也增 大了页面的大小。如果已经对css和js做了缓存,那也就没有2次多余的http请求了。当然,我在前面中也说过,有些特殊的页面开发人员还是会选择内联 的css和js文件。

第九条、减少DNS查询 (Reduce DNS Lookups)

在 Internet上域名与IP地址之间是一一对应的,域名(kuqin.com)很好记,但计算机不认识,计算机之间的“相认”还要转成ip地址。在网络 上每台计算机都对应有一个独立的ip地址。在域名和ip地址之间的转换工作称为域名解析,也称DNS查询。一次DNS的解析过程会消耗20-120毫秒的 时间,在dns查询结束之前,浏览器不会下载该域名下的任何东西。所以减少dns查询的时间可以加快页面的加载速度。yahoo的建议一个页面所包含的域 名数尽量控制在2-4个。这就需要对页面整体有一个很好的规划。目前我们这点做的不好,很多打点的广告投放系统拖累了我们。

第十条、压缩 JavaScript 和 CSS (Minify JavaScript )

压缩js和css的左右很显然,减少页面字节数。容量小页面加载速度自然也就快。而且压缩除了减少体积以外还可以起到一定的保护左右。这点我们做得不错。常用的压缩工具有JsMin、YUI compressor等。另外像http://dean.edwards.name/packer/还给我们提供了一个非常方便的在线压缩工具。你可以在jQuery的网页看到压缩过的js文件和没有压缩过的js文件的容量差别:

当然,压缩带来的一个弊端就是代码的可读性没了。相信很多做前端的朋友都遇到过这个问题:看Google的效果很酷,可是去看他的源代码却是一大堆 挤在一起的字符,连函数名都是替换过的,汗死!自己的代码也这样岂不是对维护非常不方便。所有阿里巴巴中文站目前采用的做法是在js和css发布的时候在 服务器端进行压缩。这样在我们很方便地维护自己的代码。

第十一条、避免重定向 (Avoid Redirects )

不久前在ieblog上看到过《Internet Explorer and Connection Limits》这篇文章,比如 当你输入http://www.kuqin.com/ 的时候服务器会自动产生一个301服务器转向 http://www.kuqin.com/ ,你看浏览器的地址栏就能看出来。这种重定向自然也是需要消耗时间的。当然这只是一个例子,发生重定向的原因还有很多,但是不变的是每增加一次重定向就会增加一次web请求,所以因该尽量减少。

第十二条、移除重复的脚本 (Remove Duplicate Scripts )

这点我想不说也知道,不仅是从性能上考虑,代码规范上看也是这样。但是不得不承认,很多时候我们会因为图一时之快而加上一些或许是重复的代码。或许一个统一的css框架和js框架可以比较好的解决我们的问题。小猪的观点很对,不仅是要做到不重复,更是要做到可重用。

第十三条、配置实体标签(ETags) (Configure ETags )

这点我也不懂,呵呵。在inforQ上找到一篇解释得比较详细的说明《使用ETags减少Web应用带宽和负载》,有兴趣的同学可以去看看。

第十四条、使 AJAX 缓存 (Make Ajax Cacheable )

ajax还要去缓存?做ajax请求的时候往往还要增加一个时间戳去避免他缓存。It’s important to remember that “asynchronous” does not imply “instantaneous”.(记住“异步”不是“瞬间”这一点很重要)。记住,即使AJAX是动态产生的而且只对一个用户起作用,他们依然可以被缓 存。

Java多线程设计要点

1.多线程中有主内存和工作内存之分, 在JVM中,有一个主内存,专门负责所有线程共享数据;而每个线程都有他自己私有的工作内存, 主内存和工作内存分贝在JVM的stack区和heap区。

2.线程的状态有’Ready’, ‘Running’, ‘Sleeping’, ‘Blocked’, 和 ‘Waiting’几个状态,’Ready’ 表示线程正在等待CPU分配允许运行的时间。

3.线程运行次序并不是按照我们创建他们时的顺序来运行的,CPU处理线程的顺序是不确定的,如果需要确定,那么必须手工介入,使用setPriority()方法设置优先级。

4.我们无从知道一个线程什么时候运行,两个或多个线程在访问同一个资源时,需要synchronized

5. 每个线程会注册自己,实际某处存在着对它的引用,因此,垃圾回收机制对它就“束手无策”了。

6. Daemon线程区别一般线程之处是:主程序一旦结束,Daemon线程就会结束。

7. 一个对象中的所有synchronized方法都共享一把锁,这把锁能够防止多个方法对通用内存同时进行的写操作。synchronized static方法可在一个类范围内被相互间锁定起来。

8. 对于访问某个关键共享资源的所有方法,都必须把它们设为synchronized,否则就不能正常工作。

9. 假设已知一个方法不会造成冲突,最明智的方法是不要使用synchronized,能提高些性能。

10. 如果一个\”同步”方法修改了一个变量,而我们的方法要用到这个变量(可能是只读),最好将自己的这个方法也设为 synchronized。

11. synchronized不能继承, 父类的方法是synchronized,那么其子类重载方法中就不会继承“同步”。

12. 线程堵塞Blocked有几个原因造成:

(1)线程在等候一些IO操作
(2)线程试图调用另外一个对象的“同步”方法,但那个对象处于锁定状态,暂时无法使用。

13.原子型操作(atomic), 对原始型变量(primitive)的操作是原子型的atomic. 意味着这些操作是线程安全的, 但是大部分情况下,我们并不能正确使用,来看看 i = i + 1 , i是int型,属于原始型变量:

(1)从主内存中读取i值到本地内存.
(2)将值从本地内存装载到线程工作拷贝中.
(3)装载变量1.
(4)将i 加 1.
(5)将结果给变量i.
(6)将i保存到线程本地工作拷贝中.
(7)写回主内存.

注意原子型操作只限于第1步到第2步的读取以及第6到第7步的写, i的值还是可能被同时执行i=i+1的多线程中断打扰(在第4步)。

double 和long 变量是非原子型的(non-atomic)。数组是object 非原子型。

14. 由于13条的原因,我们解决办法是:

class xxx extends Thread{ //i会被经常修改 private int i; public synchronized int read(){ return i;} public synchronized void update(){ i = i + 1;} .......... }

15. Volatile变量, volatile变量表示保证它必须是与主内存保持一致,它实际是”变量的同步”, 也就是说对于volatile变量的操作是原子型的,如用在long 或 double变量前。

16. 使用yield()会自动放弃CPU,有时比sleep更能提升性能。

17. sleep()和wait()的区别是:wait()方法被调用时会解除锁定,但是我们能使用它的地方只是在一个同步的方法或代码块内。
18. 通过制造缩小同步范围,尽可能的实现代码块同步,wait(毫秒数)可在指定的毫秒数可退出wait;对于wait()需要被notisfy()或notifyAll()踢醒。

19. 构造两个线程之间实时通信的方法分几步:
(1). 创建一个PipedWriter和一个PipedReader和它们之间的管道;
PipedReader in = new PipedReader(new PipedWriter())
(2). 在需要发送信息的线程开始之前,将外部的PipedWriter导向给其内部的Writer实例out
(3). 在需要接受信息的线程开始之前,将外部的PipedReader导向给其内部的Reader实例in
(4). 这样放入out的所有东西度可从in中提取出来。

20. synchronized带来的问题除性能有所下降外,最大的缺点是会带来死锁DeadLock,只有通过谨慎设计来防止死锁,其他毫无办法,这也是线程 难以驯服的一个原因。不要再使用stop() suspend() resume()和destory()方法

21. 在大量线程被堵塞时,最高优先级的线程先运行。但是不表示低级别线程不会运行,运行概率小而已。

22. 线程组的主要优点是:使用单个命令可完成对整个线程组的操作。很少需要用到线程组。

23. 从以下几个方面提升多线程的性能:

检查所有可能Block的地方,尽可能的多的使用sleep或yield()以及wait();

尽可能延长sleep(毫秒数)的时间;

运行的线程不用超过100个,不能太多;

不同平台linux或windows以及不同JVM运行性能差别很大。