易栈网-膘叔

老王的看法，不过，事实上就是这样，现在很多开发人员还是很少在运行时候把对象作为参数传给某个方法或者class

原文：http://hi.baidu.com/thinkinginlamp/blog/item/ea586b63472627680c33fa38.html

正文：

写在前面的话：PHP每次运行重建环境，这样的运行方式本身就决定了PHP没有传统意义上的单例。

单例模式（singleton）也被叫做单件模式。使用它的目的是为了确保某个类只有一个实例。因为它的实现方式很简单，所以多数模式书籍都把单例模式作 为入门模式来介绍，可以说对很多模式爱好者来说，单例模式是他们最熟悉的设计模式。可惜这间接造成了单例模式使用的泛滥，以至于到了无所不在的地步，比如 说，ZendFramework里连前端控制器都是单例的。那么，单例模式是邪恶的么？

下面看一个实际编程时很多人愿意采用的单例模式例子：

注意：正常的单例模式应该设置一个私有化的__construct，但是出于下文的需要，我省略的它，至于限制__clone的行为，因为我嫌它占地方， 所以也没写，这两点你自己注意一下就好了，和文本讨论的问题关系不大。完整的例子可以参考：http://www.php.net/manual/en /language.oop5.patterns.php。

class Database
{
    private static $instance;

    public static function getInstance()
    {
        if (!isset(self::$instance)) {
            $class = __CLASS__;
            self::$instance = new $class;
        }

        return self::$instance;
    }
}

如此的单例模式通常是这样调用的：

class Article
{
    private $dasebase;

    public function __construct()
    {
        $this->database = Database::getInstance();
    }
}

$article = new Article();

下面我们就来讨论一下这样使用单例模式好还是不好。

文章在构造函数内通过单例模式的方式得到数据库实例，这看起来很正常，但是对于文章这样的领域概念来说，数据库实例属于纯粹的技术实现手段，明显属于外来 物，应该尽可能隔离才对，这样才符合单一原则，在测试驱动开发的领域，这被称作MOCK，但是在上例中，由于我们是在构造函数里通过单例模式静态方法调用 得到的数据库对象，这就造成了没有办法从外部替换掉这个数据库对象。

为了克服这样的问题，按照如下的方式获取数据实例更好一些：

class Article
{
    private $dasebase;

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

$database = Database::getInstance();
$article = new Article($database);

一旦我们把数据库实例化的过程放到了外面，便可以随意替换掉其具体的实现方式，这很棒，特别是在测试的时候很有用，因为数据库环境是一个很大的不安定因 素，替换掉它有助于让测试用例更高效的运行。你甚至可以把程序搞得再智能化一点，一切外部对象依赖都通过容器注入的方式挂接。

此时再看看上面代码里的$database = Database::getInstance($database);突然又感觉有点莫名其妙，因为实在看不到在这里使用单例模式有什么额外的好处，直接按照最平常的实例化方式并没有什么不妥：

$database = new Database();
$article = new Article($database);

外部数据库对象通过构造函数的方式注入到文章里，保存在$this->database属性中，至于文章级联的评论 （$article->comments）也需要数据库实例这样的情况，可以在实例化评论的时候把文章的$this->database属性 通过评论构造函数注入的方式传递过去，当然，还有其它的方法，总而言之，你不再需要一个单例模式的数据库实例。

再回到单例模式的本意上：为了确保某个类只有一个实例。比如说公司只有一个CEO（如果有一个公司有多个CEO，那么这个公司必然会犯很多逻辑错误）。但 是反思现在很多人对单例模式的使用，往往并没有按照单例模式的本意来使用，拿上面的数据库例子来说，如果文章有一个数据库实例，评论有另一个数据库实例。 这有什么逻辑问题么？答案是没有。既然不必确保数据库只有一个实例，那么在这里使用单例模式的动机本身就值得推敲。当然，有人会说文章和评论使用不同的数 据库实例本身就低效。但如果仅仅是出于效率的考虑来使用单例模式，那么本质上不符合单例模式的定义，更何况即便不使用单例模式，我们也可以像文中的例子一 样通过注入的方式来解决所谓的低效问题。

写在后面的话：单例模式本身并不邪恶，邪恶的是在错误的环境下使用单例模式。不要为了单例而单例。

又一篇不是我写的东西，不错，对于WEB开发人员来说还是有参考意义的。所以我就贴了回来，也可以做个参考吧。。

原文：摘自：http://xinsync.xju.edu.cn/index.php/archives/4504

2006年10月份，我开始对web开发产生了兴趣，并决定自己也尝试开发一个网站。在此之前，我做过3年的java application的开发，对web开发应该算一无所知。在比较了java，php，ror，和python后，我选择了基于python的web框 架 - django 。到目前为止，我还认为这是一个明智的决定。Django高效的开发效率让我仅仅用一个月的业余时间，就基本完成了网站的开发。这是一个网络书签的网站， 我加上了一些有意思的特性，让网站显得有些与众不同。

我购买了域名和Dreamhost 的主机空间。Dreamhost支持django，并且第一年的费用只有180元人民币。2006年11月份，http: //www.hpbookmarks.com 上线了。网友们发来了善意的评论，“很有创意”，“点意思”，“一些feature很不错”。同时，还有一个非常一致的意见就是，“访问速度太慢了”。其 实，当时的情况不只是访问速度慢，而且是相当不稳定。很多时候是几个小时网站无法访问。当时，我并没有在意，因为我有两个自以为“合理”的解释。第一，我 用的是国外最便宜的虚拟主机，国内访问慢是很正常的。第二，django的还处于0.95的状态，效率和稳定性方面有问题也正常。

但是，我慢慢发现上面的解释不过是自己骗自己的借口。很多用dreamhost的网站，访问起来也很快。而且django也已经被成功应用在许多 大型的网站。我开始认真考虑提高网站速度的问题了。毕竟，速度慢的网站很可能在第一次就失去的用户，他们可以永远不会再来了。终于，我进行了下面一步一步 的优化工作，并且取得了一个看起来还不错的结果。

第一步，用Ajax提高用户体验

由于我的网站上链接字体的大小是根据点击次数决定，所以每次点击都要提交到服务器端并记录次数，再在客户端打开网站链接。这在localhost 测试的时候没有发现问题，但是部署到服务器上，会感到明显的等待。解决办法就是用Ajax。用户点击网站链接后就直接打开，再通过Ajax将点击的事件提 交到服务器端记录。这样用户感觉不到任何延时。

第二步，将逻辑移到客户端的javascript中

在开始的时候，“网站标签高亮”和“手气不错”的功能都是提交到服务器端操作，然后返回结果的。后来，我发现其实很多逻辑是可以移到客户端，由 javascript来实现的。Javascript非常强大，可以完成很多复杂的逻辑。将逻辑移到客户端的javascript中，可以很有效的减少和 服务器通讯的次数，获得更好的访问速度。

第三步，解决进程的

由于采用的是fastCGI的方式，我配置了django.fcgi。可是，我发现系统进程中，有大量的django.fcgi进程被标记为 < defunct>(失去功能)。这些进程会导致服务器有时无法正常访问。我开始尝试用命令来kill掉这些进程，但是很快发现这无法从根本上解决问 题。后来，我看到一个老外在blog上提到一个解决方案，将django.fcgi改名为dispatch.fcgi。原来，dispatch.fcgi 是一个dreamhost的系统进程，它的健壮性是可以得到保障的。果然，我将django.fcgi改名为 dispatch.fcgi后，的现象再没有出现。

第四步，优化SQL语句

SQL语句的执行通常也是一个很花费时间的操作。经过检查，我发现我的一条SQL语句，是一个嵌套三层的子表查询。而这条SQL还必须是一个 Raw SQL，即不能采用django的OR Maping。这意味着不能被cache缓存，每次都是真刀真枪的执行。更失败的是，经过我的分析，这条SQL完全可以不执行。这是一次设计上的失误，标
准的over design(过渡设计)。当时，我是想通过数据库得到一个最精确的统计值。后来发现，这个值完全可以用一个近似的常量代替。优化SQL，尤其是避免不必要的SQL执行，带来的效果是非常明显的。

第五步，尽量减少页面大小

随着添加网站越来越多，有一天我发现django生成的首页已经达到了80k。我很清楚这是一个非常不能被接受的数字。我开始检查页面，很快发现 了线索。 第一，因为偷懒，页面中很多layout是用空格( )实现的。第二，因为为了增加代码可读行，调试方便，每行生成的页面都增加换行符 (\n)。第三，最糟糕的是，大量的用了
inline css。就是将css style直接嵌入标记块中。于是，我立即动手，用css的align解决layout，去掉\n，将inline css抽象到独立的css文件中。这样下来，在不更改任何内容的情况下，80k变成了57k。（补充：由于网站链接大部分是打开新窗口，所以用了大量的 target=_blank。在ylsdd的提示下，在html的head里增加了，又节约了4k。）

第六步，用gzip进行页面压缩

当我兴高采烈的把页面优化结果贴到了smth bbs上，却被直接泼了盆凉水。原来百分之二十几的优化结果，实在太一般了。ylsdd给我了一个很重要的线索，deflate。原来apache的 deflate模块可以把文件进行gzip压缩，压缩后的文件传到浏览器后再被解压。主流的浏览器都支持这种gzip的解压操作。于是，我在apache 的配置文
件中加入了Add OutputFilter DEFAULT html css js的语句。经过测试，css，js这些文本文件的压缩后都只有原来尺寸的25%。这里，和大家分享一个网站http: //www.port80software.com/products/httpzip/compresscheck 它的作用是检测你的网站是否被压缩，以及压缩比率等。

第七步，回归静态页面

新的问题又来了。原来deflate只支持静态文件的压缩。而我的首页是django动态生成的，deflate模块没有进行压缩。我突然想到， 网站的首页为什么不能是静态页面呢？于是，我增加了一个runtime的api，这个api提供的是和原来一样由django动态生成的页面。我又写了一 个 python的程序，通过urllib2模块下载这个动态生成的页面，并保存为index.html。我将网站的root映射到index.html这个 静态页面。最后，通过linux crontab定义一个行为，每五分钟执行一下这个python程序，生成新的index.html。值得一提的是，由于网络原因，python程序不一 定每次都能准确完整的下载动态生成的页面。所以我们必须再进行一个校验算法。当页面大小要超过一定数字，页面中出现某个校验字符串的情况下，才保存 index.html。这样，每次用户提交的访问，不是由服务器端动态生成页面，极大的节省了服务器端的开销。而静态页面又可以有效的被deflate压 缩。最后结果，首页被压缩为13k，为原来的22%。唯一的区别就是，新提交和推荐的网站不能立即出现在首页。但是我认为，这应该是可以被接受的。

至此，网站的优化工作基本完成。网站的访问速度从原来30秒以上，缩短到3秒左右，应该说算是一个飞跃。虽然，3秒的速度也不是非常快，但是，考虑到虚拟主机等客观原因，这个结果我还是满意的。原来感觉我的网站很慢的朋友们，也可以再试试。

以上的优化方案出自我的个人经验，并不一定适合所有网站。但是，它告诉我们一个事实。影响网站访问速度的不仅仅是服务器配置，网络带宽。也许，你 糟糕的设计，低效率的方案也是致命的因素。应当注意的是，优化工作也不能匆匆上手。一定要仔细研究，具体情况具体分析，得到统计数据，找到真正的问题所 在，再开始优化。相信自己，提高网站的访问速度并不是不可能。毕竟，Nothing is Impossible。祝大家成功。

本文来自冰山上的播客：http://xinsync.xju.edu.cn/index.php/archives/4476
还是值得记录一下，虽然效果一样，但正因为优先级的不同，导致结果可能会和预料中的值有偏差，虽然实际应用中不太用得到但，看看还是好的
原文：

<?php
$true = TRUE;
$false = FALSE;
$rt1 = $true && $false;//$rt1:FALSE
$rt2 = $true and $false;//$rt2:TRUE

var_dump($rt1);//FALSE
var_dump($rt2);//TRUE
var_dump($true && $false);//FALSE
var_dump($true and $false);//FALSE

$rt1 = $true && $false;
$rt2 = $true and $false;

$rt1 = ($true && $false);
($rt2 = $true) and $false;

var_dump($rt1 = $true && $false);
var_dump($rt2 = $true and $false);

网页打开速度到底对用户行为有什么影响，恐怕没几个人能够说清楚吧。以下内容来自博客园独孤一草摘抄的文章，他是摘了其中一段，我也就把他摘抄的部分再次摘抄回来，他的原文地址是：http://www.cnblogs.com/shoudu/archive/2009/03/26/1421928.html

网页打开的最佳速度

2秒！

许多研究都表明，用户最满意的打开网页时间，是在2秒以下。用户能够忍受的最长等待时间的中位数，在6～8秒之间。这就是说，8秒是一个临界值，如果你的网站打开速度在8秒以上，那么很可能，大部分访问者最终都会离你而去。

研究显示，如果等待12秒以后，网页还是没有载入，那么99%以上的用户会关闭这个网页，不再等待。

但是，如果在等待载入期间，网站能够向用户显示反馈消息，比如一个进度条，那么用户可以忍受的时间会延长到38秒。

对访问者的心理影响

根据一些抽样调查，访问者倾向于认为，打开速度较快的网站质量更高，更可信，也更有趣。

相对应地，网页打开速度越慢，访问者的心理挫折感就越强，就会对网站的可信性和质量产生怀疑。在这种情况下，用户会觉得网站的后台可能出现了一些错 误，因为在很长一段时间内，他没有得到任何提示。而且，缓慢的打开速度会让用户忘了下一步要干什么，不得不重新回忆，这会进一步恶化用户的使用体验。

这个指标对电子商务网站尤其重要。载入速度越快，就越容易使访问者变成你的客户，降低客户选择商品后、最后却放弃结账的比例。

不过，网站反应速度也不宜太快，否则用户会增加与服务器互动的频率，这可能加大出现错误的概率。

一些实证结果

Google做过一个试验，显示10条搜索结果的页面载入需要0.4秒，显示30条搜索结果的页面载入需要0.9秒，结果后者使得Google总的流量和收入减少了20%。

Google地图上线的时候，首页大小有100KB，后来下降到70~80KB。结果，流量在第一个星期上升了10%，接下来的3个星期又再上升了25%。

Amazon的统计也显示了相近的结果，首页打开时间每增加100毫秒，网站销售量会减少1%。

宽带与窄带的区别

有研究显示，宽带用户比窄带用户更没有耐心。宽带用户愿意忍受的最长等待时间，往往只有4～6秒。

网站制作者必须记住，在ADSL条件下，3~5秒就能载入的网页，在窄带条件下需要20~30秒才能打开。因此，网页总的大小——包括图片、Javascript和CSS文件的大小——不宜过大，这样对宽带和窄带用户都有利。

本来不想转这个的，因为原文好象不全，但我试着将原文最后一句去掉，好象也能读的通，就先转上来看看了。。。

原文：http://netsecurity.51cto.com/art/200902/112190.htm

IE有一个特性，那就是在将一个文件展示给用户之前会首先检查文件的类型，这乍看起来并没什么问题，但实际上这是相当危险的，因为这会允许IE执行 图片中的代码，即嵌入在一个图像中的JavaScript代码。引入MIME sniffing功能的初衷是用来弥补Web服务器响应一个图像请求时有可能返回错误的内容类型信息这一缺陷。

但是事不遂人愿，心怀不轨的人可以轻易滥用这一特性，如通过精心制作一个图像文件，并在其中嵌入可以被浏览器所展示和执行的HTML和JavaScript代码。本文将深入考察该问题，并为用户和网站开发人员介绍如何降低此问题带来的风险。

一、危险的MIME sniffing功能

对于Web 2.0应用程序来说，允许用户上载图像是一项基本的要求。但是，IE用户面对这些图片时却要小心了，因为IE的某些功能会为利用图片进行跨站点脚本攻击大开方便之门。

虽然许多大型站点都设法保护其访问者免受可能的JavaScript攻击，例如实现专门用于防御活动内容的过滤器等，但是他们却无法跟活动内容一刀 两断，因为对于个人简介、博客和论坛来说，JavaScript、HTML 代码和Flash小应用程序是不可或缺的活动内容。

此外，大部分交互型站点都允许用户上载和链接他们的图片，但是攻击者却可以利用此功能来颠覆IE为保证兼容性和提供额外的安全性而引入的某些功能。 攻击者只需在图像的开头部分嵌入一些HTML代码和JavaScript，那么当IE打开这个做过手脚的图像时，浏览器所做的不是显示图像，而是检测并运 行图像中嵌入的代码。

之所以出现这种情况，是因为浏览器可以用来确定文件类型的方式多种多样，例如文件扩展名jpg可以指出一个图像为JPEG格式，此外Web服务器还 可以在HTTP报头中定义Content-Type（在本例中为image/jpg），但是一般说来使用上载的文件的文件名扩展部分来指出文件的类型。

最后，大多数 Web 浏览器还会检查一个文件的开始几个字节（即通常所说的文件的“签名”），这几个字节通常为一些众所周知的字节序列，例如PNG、PK、JPEG、JFIF等等。

迄今为止，我们介绍了浏览器可以确定文件内容类型的三种方法，即通过文件本身的扩展名或文件开头部分的签名，或通过服务器响应报头Content-Type来确定文件类型。

不过，后来IE4引入了第四种方法，即通常所说的MIME sniffing或者MIME类型检测方法。所以，现在的IE版本都不自动地假定来自web的文件的内容类型就是服务器在HTTP报头中的所声明的内容类 型。IE浏览器既不信任文件名扩展部分，也不信任签名，相反，它是通过检查文件开头的256字节内容来确定文件的类型。

然而，只有当用户直接调用URL下载文件时IE才这样做。当使用IE打开HTML中的图像标签(IMG)所连接的本地存储的文件或者图像的时候，则不会进行嗅探。

IE引入MIME sniffing功能的初衷是用来提防服务器给出的错误内容类型指示的，但是攻击者却利用它来规避IE中的安全防御功能，即防止浏览器自动地执行所下载的文件（如hta文件）的那些功能。

此外，MIME sniffing还使得浏览器能够容忍在Content-Type声明中的偶然性错误，例如，如果服务器声明某文件类型为text/plain文件，然而实际提供的却是一个HTML文件，那么IE将它作为HTML处理。

对于常见的GIF、JPEG和PNG格式，只要文件扩展名、Content-Type和签名所指的类型相一致，那么浏览器就会对MIME sniffing所得到的结果置之不理。只有当文件扩展名、Content-Type和签名所指的类型有出入时，IE才会以MIME sniffing所确定的结果为准。

二、倒打一耙的MIME sniffing功能

现在，如何保护用户免受恶意服务器的侵害与如何为不正确地配置服务器的管理员提供有效帮助已经成为Web 2.0所面临的一大问题。 如果文件的扩展名、Content-Type和签名相抵触，那么浏览器会以内容为准。

所以，如果一幅图片的开头部分为一些HTML代码的话，虽然乍一看好像是无害的，但是实际上却可能相当危险，因为IE会执行图片中的代码。这为攻击 者把JavaScript嵌入图像提高了一个机会，所以他们可以利用这种方式执行跨站点脚本攻击，使用精心制作的图像来窃取受害者在当前访问的服务器上的 身份验证cookie，然后以受害者的身份登录到那个服务器。

三、援兵未至

微软公司已经认识到这个问题，并计划IE的新版本中加以修复。IE8不再探测图像，因此，它会忽略嵌入的HTML。此外，对于特定的下载，还可以通 过为私有的Content-Type以及authoritative指定值来关掉MIME sniffing功能，例如content-type=text/html; authoritative=true;。然后，IE会把文件当作服务器指出的类型来处理。

关键情况下，可以使用新的“X-Download-Options: noopen”头部来确保在站点上下文的外部显示相应的文件，这意味着即使HTML文件也能够安全的投递，因为浏览器只是将文件保存起来而已。遗憾的 是，IE8要想全面替代其他版本的IE尚需时日，在此之前，Web站点对此还是指望不上的。

四、急救措施

实际上，如今想要抵挡这些精心制作的文件也并非难事。自Windows XP SP2以来，用户已能禁用IE中的MIME sniffing功能，方法是打开浏览器的“工具”菜单中选择“Internet 选项”，点击“安全”选项卡，在“请为不同的区域的Web内容指定安全设置（z）”下面选择“Internet”图标，在“该区域的安全级别（L）”下面 点击“自定义级别”按钮，最后启用“基于内容打开文件，而不是文件扩展名”选项即可。然而，这样做会重新开放一些以前的古老漏洞！

这是否能够提供安全性只能够靠实践来证明。我们的重点不应该放在在用户间推广这个技巧，而是应该设法让web服务应用提供安全保障措施来保护访问者，并确保Web服务提供方的系统不向用户传送精心制作的图像。

管理员可以使用脚本检查上传到其服务器中的文件的类型的一致性。举例来说，如果某图像的文件名扩展部分为.jpg，并且文件起始字节部分的签名也指 出是相同的类型（在Linux下可以使用file image.jpg命令，而在PHP中可以使用getimagesize加以印证），经过上述验证后，服务器才能发出该文件。

这样，即使文件包含HTML 代码，IE也不会执行这些代码。然而要注意的是，通过这种方式只能保护图像的安全，同时服务器声明的Content-Type必须完全正确才行。 这个方法对其它格式均不起作用。

然而，要想达到绝对的可靠性，需要检查文件的前256字节是否HTML 代码