PHProxy(http://sourceforge.net/projects/poxy/)，是一款PHP代理程序，它的好处是：让你在受限网络环境下，访问被禁止的网站，它的典型使用情况如下：

• 如果你的公司禁止员工在上班时间上一些SNS、财经网站等，通过这个程序，可以让你绕过限制
• 如果你想访问墙外的网站，比如Twitter、Facebook等一些人不想让你看的网站，请用PHProxy(这个是本文存在的目的)

当然不是每个人都可以使用它的，前提是：

• 你必须有自己的web站点
• 你的空间提供商允许你做proxy服务，坏消息是大部分空间提供商都禁止用户安装代理程序，比如我的空间商，明确规定：

Anonymous Proxies. HostMonster.Com does not allow the use of anonymous proxy scripts on its servers. They can be very abusive to the server resources, affecting all users on that server.

• 如果你想访问墙外的网站，即使你符合上面两点也是不行的，你的网站必须位于墙外，且你必须修改一下这个程序的代码，请看下面的介绍：

安装PHProxy后，我发现，用它来访问普通网站，是没有问题的，你无需修改它的代码，但是如果你用来访问被GFW墙掉的网站，就不行了。比如：http://www.twitter.com

为什么呢？因为PHProxy首先会将你访问的网站URL，缺省进行一次Base64编码，所以twitter的URL就变成了aHR0cDovL3d3dy50d2l0dGVyLmNvbQ==，然后才进行一次URLEncode编码，变成了aHR0cDovL3d3dy50d2l0dGVyLmNvbQ%3D%3D，而这个字符串大概已经上了GFW的黑名单，不信的话，你用Google搜索下：aHR0cDovL3d3dy50d2l0dGVyLmNvbQ%3D%3D，你的浏览器立刻被重置。

知道原因就简单了，我们只要修改PHProxy，在URL->Base64 Encoder->URL Encoder这个过程后，再加上一道自己定义的编码即可，比如，你把每个字符都加1，解码的时候，再反过来做即可。GFW只会把这些知名站点的URL的用缺省编码加入黑名单，不可能把你新方法加工后的字符串也加入黑名单，因为太多了。

下面做个实际的例子，比如我们可以在编码URL后，将前2位调换到尾部，解码的时候做相反的操作:

else if ($_flags['base64_encode'])
{
    function encode_url($url)
    {
        $tmp = rawurlencode(base64_encode($url));   
        $head = substr($tmp, 0, 2);
        $tail = substr($tmp, 2);
        return $tail.$head;

        // return rawurlencode(base64_encode($url));    
    }
    function decode_url($url)
    {
        $head = substr($url, -2);
        $tail = substr($url, 0, strlen($url) -2);
        $url = $head.$tail;       
        return str_replace(array(‘&’, ‘&’), ‘&’, base64_decode(rawurldecode($url)));
    }
}

上面的代码，我已经验证，可以逃过GFW的封锁。你可以用你自己的喜欢的方式，替换绿色的部分。

注：PHProxy还可以使用ROT13编码，但同样也被屏蔽了，请做同样的Hack。

[ad]

MySQL是个非常优秀的免费数据库，下面是我周末做Data Purge的部分记录，可以用做将来的参考之用：

硬件：AMD Opteron 265 1.8G(Cache 1M), RAM:1G, HD: 350G，算是配置比较差的一台服务器。请注意，下面所提到的数据和您的服务器性能有很大的关系。

// Delete Data
2009-09-03 19:45:45 Start…
Row Count: 46500394(46M)
DELETE FROM atedata WHERE DATE < ’2009-06-01 00:00:00′
Row Count: 22699749(22M)
2009-09-03 21:18:06 End…

从上面可以看出，删除数据是比较慢的操作，46M条的数据，删除到22M条，总共用了大概93分钟，大概255,921rows/min。删除操作所需时间主要和将要删除的数据量是成正比的，删除的记录数越多，所用的时间也越多。

// Optimize Table
2009-09-04 21:33:54 Start…
Row Count: 23051455(23M) – 7.1GiB
optimize table atedata
Row Count: 23051455(23M) – 3.4GiB
2009-09-04 22:15:37 End…

对于数据量比较大的表，比如超过1G，如果只是简单的用DELETE删除了数据，这些数据所占据的磁盘空间并没有被释放，在MySQL里我们称之为：Overhead。只有对表做了OPTIMIZE操作，才能真正的释放它。

从上面的数据可以看出，优化前，表大小是7.1G，优化后表大小为3.4G，表的记录数没有变化，用时42分钟，平均88MiB每分钟。该操作耗时大致和(Table Size – Overhead)的差成正比。对于那种比较大的表，千万不要删除了几百条记录就做Optimize操作，因为它太耗费时间了，我们可以累积到一定数量再做。

Optimize命令执行后，MySQL会生产一个临时的.TMD文件，MySQL的状态显示Repair by sorting，它其实就是优化后的表。这个过程很漫长，做完后，还有一步是重建索引，MySQL状态显示Repair with Keycache，结束的时候会有个.TMM的临时文件生成，它可能就是.MYI文件的拷贝，不过官方文档没有说明，只是猜测。

在创建索引文件的过程中(Repair with Keycache)，它的耗时和表的索引多少有很大的关系，我没有验证，但我们可以猜测：索引越多，这个过程就越长。

由于在表很大的情况下，做类似DELETE、OPTIMIZE、ALTER等操作，都是非常的耗时间，所以我们在设计系统的时候就需要提前考虑到：

1. 保存数据的时间长度
2. 做Data Purge的周期、方法策略
3. 数据备份的策略
4. Data Purge的过程中，系统该如何应对（以上操作都会造成MySQL被锁定，数据库无法使用）
5. 等等

如果数据量不大的话，另当别论。

[ad]