源字符串：<script type="text/javascript">adsfadfsdasfsdafdsfsadfsa</script>

匹配要求，匹配<script….>….</script>标签里面所有内容，包括改标签

常见写法(1)，因为<script后面可能出现字符、空白、特殊符号等，还有标签里面也可能出现各种js代码。我们简单方法是：

正则表达式：<script.*?>.*?</script> (测试工具使用了：regexBuddy)

总共花费115步，回溯了：48次。 因为我们使用”.”字符，匹配默认情况下除了\n之外所有字符。

方法（2），我们分析特点发现，<script…>后面，应该是除了”>”之外都可以字符，然后一对<script>标签里面js内容。可以定义为除了”<”之外。（这里面我只是举例说明优化方法，实际网页中script标签里面，常见都会出现有”<”字符了）

正则表达式：<script[^?>]+>[^<]+</script>

19步，0次回溯！ ，步骤只有原先的15%左右，性能几倍的提升了！

从上面我们看到，不同正则表达式，对通用字符配平，性能相差会很大。减少“回溯”是最好的方法，减少回溯其中最主要的方法是：”用最小范围的元字符，尽量避免用过大的元字符！”。一般规律如下：

1、使用正确的边界匹配器（^、$、\b、\B等），限定搜索字符串位置

2、使用具体的元字符、字符类（\d、\w、\s等） ，少用”.”字符

3、使用正确的量词（+、*、?、{n,m}），如果能够限定长度，匹配最佳

4、使用非捕获组、原子组，减少没有必要的字匹配捕获用(?:)

如：我想匹配一些英文字母，它后面接的是数字。如：abc1234,我可以写 “\w+\d+”，也可以写”[a-zA-Z]+\d+” ，其中第一个\w+会先匹配所有abc1234，然后回溯，匹配满足\d+格式。一共4步，而后面这个只需要2步，步骤减少一半了！好了，今天就先到这里，欢迎大家讨论、交流！

• 为什么需要性能测试工具

我们都知道，正则表达式使用进行搜索查找，没有字符串直接查找快！而且性能是几何倍数下降。那么，为什么正则表达式速度会比字符串搜索慢呢。我们来看看，正则表达式查找字符串的匹配过程吧。正则表达式由一些元字符，普通字符，量词字符组合成。默认情况下，这些量词元字符（*,+,?)都是贪婪模式，会最大长度匹配字符串。我们知道，正则表达式往往搜索路径会有多个，我们看看，下面匹配过程。就知道，主要影响正则表达式执行性能有哪些了。

正则表达式匹配过程如：\d+abc，元字符是：”12345bdc”，查找会从左向右进行，\d+，贪婪模式，一下子匹配到12345，然后bdc与\d+不能匹配，”abc”中,”a”字符，开始匹配”bdc”，发现匹配失败。正则表达式开始回溯匹配（贪婪模式量词开始逐一减少匹配字符长度)，\d+只匹配”1234”，”5bdc”与”abc”匹配，任然失败。\d+继续减少匹配长度为：”123”，”45bdc”与”abc”匹配，任然失败。继续回退，直到\d+匹配”1”，用”2345bdc”与”bdc”匹配，任然失败。整个匹配就失败了。

从上面过程中，我们发现，每次回溯，要重新操作匹配因此匹配搜索次数，直接影响正则表达式的性能。做正则表达式性能优化，一般就是优化查询的次数。这个是我们分析过程，如果有个工具能够实实在在看到每一步匹配过程，对于我们优化正则表达式将带来太多方便了。这里介绍工具是：regexbuddy软件，它就是一个实实在在看到匹配过程工具。

• regexbuddy工具怎么样使用，使用介绍

1、安装完regexbuddy

该工具支持多种程序语言正则表达式，如：perl,pcre,javascript,python,ruby,c#,java等等，还能自动生成程序代码，并且内部带有大量的常用正则表达式。

2、一般切换到side by side：

3、匹配过程

从上面一个匹配看，这个简单一个匹配，搜索了8次，进行了不断查找。如果我们已经准确知道自己要匹配什么样字符，我们可以对源正则表达式修改下，减少匹配次数。就达到优化正则表达式目的，提高匹配效率！

后记：这个工具是不是很强大呢，你知道在baidu搜索，该关键字：regexbuddy，就可以方便下载到。通过该工具，对我们写出好的高性能正则表达式确实能带来很大帮助。有时候可能一个小小修改，自己程序正则表达式匹配速度可能几个数量级的提升。好了，欢迎大家交流，你有好的工具、方法，欢迎留言，可以给更多朋友分享！

• 我用file 存放用户session

session默认以文件保存，当一个用户访问session_start页面后，这个时候，就会默认创建一个包含session_id文件名，并且这个时候，会对文件进行锁定。如果这个用户点击链接，又访问一个该站session_start网页。这是，由于session_id一样，这个页面也有读取锁定该用户存放session文件。 由于，第一个页面没有执行完，它一直锁定了该文件。 第2个页面就不能获取锁，一直处于等待状态。

这样一个看似小的问题，实际上，如果网站上面有大量用户访问，会导致session读取文件一直阻塞等待着。用户浏览器一直跟服务器保持连接，会消耗很多服务器资源。web服务器活跃连接数也会增大，可能很快就会耗费完连接资源，出现拒绝服务器。

• 我用memcache 存放用户session

用memcache保存用户session，相比读取文件有很大速度提升。而且可以做到多服务器共享session。确实很方便，这个时候，我们发现不会出现用文件保存session锁定清理。memcached读取时候，是共享的，不会出现等待。但是，我们会发现，memcached连接数，还是会保持着。并且，连接数会增加，如果这个时候，你设置的memcached连接数过小，你会发现，很快memcached就挂死了。 这也是，做memcache接管session时候，经常遇到问题。 有时候，web服务器很多，session(memcache)很少。发现memcache莫名其妙死掉，可能跟这个有关系。太多反映很慢的页面(启动session)，会导致占用了大量memcached连接数。

• 改变session使用习惯、优化调用方法

其实，通过file或者session，如果处理耗时页面，都会带来服务器资源很大消耗。其实我们一般写入session或者读取时候，如果自己能够控制。用完了，就关闭掉文件锁，或者mem连接。就会自动释放资源，其实，php里面的：session_write_close，session_commit 函数就能做到改功能。我们看下下面代码执行过程：

<?php
ini_set('session.save_path','/tmp/');

function open($save_path, $session_name)
{
	echo __FUNCTION__,"<br />";
	return(true);
}
function close()
{
	echo __FUNCTION__,"<br />";
	return(true);
}
function read($id)
{
	echo __FUNCTION__,"<br />";
}
function write($id, $sess_data)
{
	echo __FUNCTION__,"<br />";
	return(true);
}
function destroy($id)
{
	echo __FUNCTION__,"<br />";
	return(true);
}
function gc($maxlifetime)
{
	echo __FUNCTION__,"<br />";
	return true;
}
session_set_save_handler("open", "close", "read", "write", "destroy", "gc");
register_shutdown_function('test');

function test()
{
	echo __FUNCTION__,"<br />";
}
session_start();
echo 'aaaaa',"<br />";

启动”session_start” 会自动执行,open,read函数，然后页面执行完，会执行shutdown函数，最后会把session写入进去，然后执行close关闭文件。从session_start 到页面结束，会一直锁定文件或者保持连接的。

我们如果 执行完session_start后，执行”session_commit();” 看看结果

执行过程：执行commit后，直接会调用，wirte,close操作。直接关闭文件或者关闭连接(memcache)了。

• 我们的问题

1.我们页面有多次写入，怎么样操作？

第一次写入后，然后提交，再次打开写入，然后再次提交。我们发现，2次数据都保存到用户session中了。

• 我们来总结下吧

1.只读取session页面，建议打开后，就直接commit，这是$_SESSION变量已经生成了。

2.有对session进行写入页面，建议修改完$_SESSION后，直接调用commit

3.多次打开并且写入，这个不建议使用，比较打开文件，写入都是耗费时间的。如果能一次搞定的，就不要做多次了。 除非，中间执行很耗时的业务。

后记：其实，使用完session，随手commit也不是坏事，养成习惯后。可以节省性能，减少服务器开销。是个不错选择！欢迎大家交流！

• 相对路径带来问题

我们有如下结构的目录。

<web>(网站根目录)
├<a>文件夹
│ │
│ └a.php
├<b>文件夹
│ │
│ └b.php
└test.php

如果b.php 包含a.php (include(“../a/a.php”)) ，然后test.php 包含b.php (include(“b/b.php”)) ，我们发现很奇怪问题。

首先访问：b.php 可以正常访问， 然后访问test.php

发现，找不到 a.php了。 这里注意一个问题是：php 默认相对路径都是以，被访问页面所在路径为准的。无论一个入口页面，里面包含多少文件，相对路径，都是以这个页面为准。

如果访问test.php 根路径是：test.php，如果访问b.php 相对路径都以b.php 所在路径为准。刚刚页面test.php 包含了b.php,b.php包含了a.php. 所有包含都以test.php 为准的。

估计刚刚开始php学习朋友，经常遇到这个问题，而且发现经常出现一大堆警告影响大家学习的兴趣。

• 使用绝对路径方法

各大开源框架基本上采用绝对路径方法，这样可以避免相对路径因为包含访问文件变了。基准路径变化，让包含出现错误了。 所以，我们看看常见方法。

首先将网站基准订到一个固定文件。一般可以用下面方法实现。如：根目录下面有个config.php文件。

<?php

define(‘Root_Path’,dirname(__FILE__));

__FILE__ 至的是当前脚本路径，在那个脚步php里面调用该变量，它的值就是该脚步的绝对路径。

然后，任何其它页面，在做包含时候，只需要包含了该config.php后。

<?php

包含config.php…..

include(Root_Path.”/文件路径”);即可

• 使用绝对路径好处

使用解决路径好处除了可以在大型项目中，包含时候更准确定位到文件，不易产生错误外。还有另外一个好处，包含文件，性能会得到很大提升。

如果给一个相对位置包含，php查找该文件，一般会在set_include_path 函数，设置的所有路径里面去搜索。 我们知道，要一个一个去尝试，列举目录，然后查找文件。这直接会消耗大的IO。 也会消耗很多性能。 如果我们用绝对包含，直接就可以准确判断出，文件是否存在。不会去set_include_path设置目录去查找了。

以上问题，对于刚刚接触到php大型项目开发，可能会很容易遇到。欢迎讨论！

刚开始，下载一套wordpress 3.5，然后一路安装下来，比较简单，跟常见其它一些开源平台查不到。 只要配置好数据库连接，然后一路下一步，分把钟就可以做好。 也是由于，对wordpress 早已经有所耳闻，而且感觉它名气很大，这类系统中佼佼者。

• 首先看看它数据库结构吧

11张表，实现了强大的博客功能，首先表示不简单。现在很多cms 基本上都是40-50个表。其中很有几张表，设计为窄表，基本上类似，类型，键值名，键值。类似近年的NoSql类型数据库。都是键值对。读取灵活，扩展方便。 可能就是，开发时候复杂些。这类基本设计是：posts,postmeta表，所有文章都具备的通用字段，就放到posts表，而针对文章进行属性设置，如：访问数，tag，权限等。都放到postmeta表。如：

窄表，可以任意对一篇文章新增键值，扩展新的属性。 这也是wordpress 插件几乎可以做到无所能一个原因。 这类表可以非常灵活。新增一个属性，只需要在这个表里面，对posts ID 增加这类属性的一条记录。而且这类窄表，字段少，读取速度也很快。

感觉到表设计不足之处(个人认为，欢迎交流）

Posts表里面字段，一张表里面，居然有6个text 字段。如果读取时候，不小心select *,该会有多少磁盘IO,一条记录，该会占多少的数据块。记得刚刚，分析wordpress时候，当时一下子就看到这样情况。我毅然选择放弃该系统。也因此让我忽略了，他窄表设计优点。 个人认为，一些字段可以设置为varchar,另外text 可以移到单独posts_data表。里面只存放text字段,PostID 信息。欢迎高人指点。

• 再看看它的代码吧

现在wordpress插件有成百上千个，它基本上可以做各种系统。除了blog外，它还被改成了新闻网站，企业网站，电影网站，甚至是商城系统。这些足以说明，他前端程序一定有过人的设计架构，有它足够灵活性。

1. 看下他的目录结构吧

从这些目录，真的还没有发现它比较独特优越性。现在网上常见的MVC 结构，有独立模版目录。 这个wordpress,实际只能算，MC，而没有V，它实际上前端是通过php 直接调用include 目录里面函数而已。如：

这个也是它的一个独特特点了，国内很多模版，都会开辟自己的标签，如smarty的是：{$smarty.config.aa} 等。 而wordpress里面没有自己标签，要读取，通过函数去读。它省去了标签省去了大家学习标签成本，但大家也需要掌握N多的函数。 可以把它的函数，理解为其其它系统中定义标签。

无论是函数，还是标签，只要你在前端页面都使用这些方法，去读取你要的数据，实际上都对后端数据库做了隔离。从而让使用者不关系数据库数据了。 数据库结构修改，只要调用函数做相应跳转。前端页面还可以照样那样用。而不需要任何修改。从而保证它的稳定性。

它函数封装，不光做到从DB读取数据，通过函数，读模版，读公共包含文件，等等都做到了，函数封装。几乎做到了，所有读取数据封装（DB,file,request中），这样封装，在目前国内系统中很少见，因为为每个功能去写一堆函数，切实很多工作量。国内框架，基本上喜欢封个方法，做到很通用，然后自己去调去吧。 这个方法，可能可以读取用户表，也可以读评论，也可以读文章。 其实，看起来很通用，实际用起来就会很复杂，也会增加上手难度。我们看看wordpress 设计方法。

这只是其中的很少一部分函数，真正差不多1000把个函数呢。 因为，wordpress 函数几乎封装了所有数据调用，因此前端开发只用调用函数，就可以完成。简单容易，这也是灵活性，及得到广泛使用一个原因。

2.  看看它代码实现优点

如果说，wordpress 光只有，强大的含数据库，做到前端页面与数据直接分离。现在很多标签调用也能做到分离。 真正wordpress灵活性，以及能够扩展出各类插件，完成独特开发功能，与它独立系统分不开。

它有一个 消息机制，还有一个队列过滤模块，任务队列处理模块。这2个模块，都建立在它的一个消息机制上，普通开发方式如下：

消息机制，可以做到，前端跟实现地方解耦。这里打个比方，如一个用户完成注册，我要给用户发一个邮件，然后给管理员发一个站内信。我们以前做法是：

如果发完站内信后，还有发一个手机短信，我们必须修改注册逻辑，在接下来再增加一个发送手机短信功能。 这时，你发现任何前端修改，都需要在原先逻辑里面修改一通。 如果我们采用消息机制，程序将变为:

这个图，是改用消息模式结果，用户注册功能模块，跟接收到消息处理各个任务直接，代码没有直接关联。如果需要增加一个接收注册消息，给其它人通知一下，只需要新增一个模块，订制注册消息，然后处理一个新流程即可。

目前各类开源项目里面，消息机制已经变得非常常见了。 但在wordpress这个blog框架，它的消息主题非常完善。几乎任何动作都有消息主题发送消息。 这样让开发者，只要订制相关主题，就可以，增加自己额外处理功能。 例如： 用户发一个帖子后。检测下用户是不是有广告信息，只要订制：发帖消息，然后，增加新功能，检测内容。发现不满足，直接屏蔽帖子。

有人估计要说，这类功能，现在很多框架有类似东西，例如，页面开始有个start事件，结束有个end事件。 确实，消息概念在很多框架里面确实有用。 但是，没有这么完毕的消息主题抛出。 几乎做到整个系统任何操作，都能有消息，这样没有什么功能不能进行扩展了。

有兴趣可以去研究下，wordpress add_filter,apply_filters ，还有add_action，apply_action ，只是收到消息后，一个按顺序进行一系列元内容过滤，一个是接收元内容，进行一系列任务。

wordpress 2大优点，一个是函数封装数据操作，一个是它完善消息功能。那它有何种确定呢？

• wordpress源码不足

任何一个系统，有优点，一定有不尽人意的地方。

首先，因为它要做到自己很多函数，可以直接读取一些循环数据。或者直接读取数据库配置项。它启动时候，采用了大量的全局变量。一个大的blog,可能启动后全局变量有几百个。 有的是数据记录，有的是字符串，有的是对象。你可能会发现，这些数据可能有1，2M；无论有没有使用，这些都会先创建。可想而知，他将带来大量内存浪费。另外一个就是，可能会影响调用速度。 很多网友使用wordpress就明显有这个感觉了。

另外一个问题，其实正式来自它的消息处理模块。 它跟我们网上看到的不一样，它的消息模块是同步模块。以上面打的比方来说，尽管做到发送消息，跟处理模块代码分离。 但实际上执行过程没有多大变化，也是要先注册用户完，然后完成一些列处理功能。最好这个php页面才算处理完了。 需要时间还是那么些。 如果真的，能把这类跟功能无关接收消息，处理模块异步到后端。 那么估计再没有人抱怨wordpress打开一个要4，5秒了。

• 后记：

就说这么些了，估计很多同人告诉我说。居然它性能不好，又慢。 你干什么还要用它呢？ 这个就看你主要关注的是什么了，如果你需要快的开发模版，而且非常容易开发各种扩展。那么它是你最好选择了。 况且，性能问题，一但静态化后，几乎解决了。

估计还有人说，你既然提到它性能这么些不足，那么你有什么好的调优方法没有。 呵呵，这里欢迎大家交流意见，我也有一些想法，就先不详说，还不成熟。欢迎交流！！！祝朋友们，周末愉快！