PHPor 的blog

关于mongodb

Mon, 06 Feb 2012 17:26:33 +0000

1. 关于mongodb的遍历
db.phpor.test.find();
it

如：

2. mongodb可以在server端保存js，这样一些业务逻辑就可以使用js来写了，而且算法也不需要总是通过网络传递

关于iframe的onload事件

Wed, 01 Feb 2012 12:30:04 +0000

使用iframe来做post方式的跨域访问，通过iframe的onload事件来监听请求是否完成。
原来以为iframe的onload的事件也有跨域的限制，测试了一下，是没有的，测试了IE、火狐、safari都很好使。

 
<html> 
<head> 
<script> 
    function _onload() { // 注意，不能使用onload()，因为这本身是一个内置函数   
        alert("ok"); 
    } 
script>  
head> 
<body> 
    <iframe src="http://login.sina.com.cn/" onload="_onload();">iframe> 
body> 
html>

关于tcmalloc内存分配器

Wed, 01 Feb 2012 12:16:05 +0000

下面的8001端口进程使用的是默认的malloc内存分配器， 8002端口是使用了tcmalloc内存分配器，线上数据运行了1个月的时间，发现tcmalloc使用的内存更多一些。

关于cookie的secure属性

Wed, 01 Feb 2012 07:17:26 +0000

经过测试：（火狐下的测试）
1. http的请求可以成功设置secure cookie
2. http的请求设置的secure cookie，在http的页面中js获取不到，在https的页面中js能访问到

关于浏览器的安全模型

Mon, 30 Jan 2012 07:18:45 +0000

在使用https访问某个页面时，如果页面中包含非https的内容，则浏览器会提示包含不安全信息。那么什么情况算是“包含了不安全信息”呢？
1. 非https的图片，如：

关于P3P与第三方cookie

Sun, 29 Jan 2012 11:42:37 +0000

Safari：

设置：

火狐：

设置：

测试脚本：
稍后再补

测试结论：

safari

不识别P3P协议
默认不接受第三方cookie
对于iframe请求的第三方url设置的cookie不视为第三方cookie；对于script、img标签请求的第三方url设置的cookie按第三方cookie的设置处理；对于其他请求，还没有测试

火狐
1. 不识别P3P协议
2. 默认接受第三方cookie
3. 不管是iframe、script、img请求的第三方url设置的cookie都视为第三方cookie
IE
1. 缺省隐私等级设置为"中"——即"阻止没有合同隐私策略的第三方cookie";换言之，就是支持P3P策略

1. 其实P3P简洁策略,可以最简写成: P3P:CP=. 就OK啦,也就是说IE对P3P简介策略的支持，属于搞笑级别的.根本不看内容,至少对于第三方操作cookie是如此的.

2. IE6的实现有bug.需要注意.首次访问第三方页面,JS无法写入第三方Cookie的bug.建议尽量避免JS对Cookie的写操作.

3. 要搞定Safari,需要借助后台至少配置一个APP,与前台配合.

4. 对于第三方来说,建议避免使用JS操作Cookie,最多用来读,而不是写. 除非是和登录验证有关,否则建议使用Storage代替Cookie的使用.

参考资料：
http://www.cnblogs.com/_franky/archive/2011/03/16/1985954.html
http://hi.baidu.com/leolance/blog/item/152a1f2903f9fe22359bf706.html

小心grep 的buffer

Sun, 15 Jan 2012 16:54:39 +0000

在统计mysql查询次数时，有如下命令：

while :; do sleep 1; mysql -u user -ppass -h phpor.net -P 3306 -e 'show status like "Questions";'; done |grep Ques | awk '{print $2 - old; old = $2; }'

几秒钟后都看不到结果，怀疑是awk的buffer造成的，于是改写为：
while :; do sleep 1; mysql -u user -ppass -h phpor.net -P 3306 -e 'show status like "Questions";'; done |grep Ques | awk '{print $2 - old; old = $2; fflush();}'

依然不行，于是，把该命令推到后台，使用strace跟踪了一下awk，发现awk没有读到内容，很自然地，跟踪grep吧，发现grep read到内容了，但是总是不write，开始怀疑我的 Ques写错了，仔细比对，也没有问题呀，突然，屏幕上打印出了很多信息，于是，我恍然大悟，应该是grep的buffer搞的鬼，于是man了一下grep，果然有这方面的选项，再次修改如下：

while :; do sleep 1; mysql -u user -ppass -h phpor.net -P 3306 -e 'show status like "Questions";'; done |grep --line-buffered Ques | awk '{print $2 - old; old = $2; fflush();}'

终于OK了

一个回车与1个小时

Mon, 02 Jan 2012 19:10:07 +0000

当我执行ls命令时，文件名是多行显示的，格式很规整的。
当我执行 r=`ls`;echo $r; 时， ls的结果是输出到了一行的，原来的回车就都看不见了，不知道哪里去了。

关于tcmalloc的学习

Mon, 02 Jan 2012 15:15:49 +0000

这也是一篇关于tokyocabinet（以下简称tc）的文章。

对于tc这个东西，还是比较好用的，但是其默认的内存分配（系统的内存分配）是在令我不能满意。我的一个业务已把tc当做内存存储来使用的，所有的东西都不落地，于是我使用内存就得珍惜一点。或者说我不是我太吝啬，那个内存分配也太浪费了。本来也就1.2G的数据，在tc中折腾几天之后，使用物理内存却需要4.1G，有点儿太离谱了。所以，今天尝试一下其它的内存分配器。

tcmalloc（Thread-Caching Malloc），不要和上面的tc混淆，是一个内存分配的一个动态库。参考：
http://code.google.com/p/google-perftools/

在64位机器上，需要先安装libunwind：
http://mirror.csclub.uwaterloo.ca/nongnu/libunwind/

启用tcmalloc的两种方式：
方式一：
不需要重新编译程序，使用LD_PRELOAD=/PATH/TO/libtcmalloc.so ; 重新启动程序就行（但是你要么把启动程序包装一下，要么每次启动程序前都记着先执行一下这个操作）

方式二：
重新编译程序，编译时，使用选项：
-ltcmalloc
这样，启动的是否就一定是这种内存分配方式了，但是，你也不可能再使用默认的分配方式了

参考资料：
http://www.tektalk.org/2011/10/20/tcmalloc%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90%E6%80%BB%E6%8B%AC/
http://blog.csdn.net/yfkiss/article/details/6902269
http://goog-perftools.sourceforge.net/doc/tcmalloc.html

-----------------------------------------------
我的测试程序已经跑了一个小时了，似乎tcmalloc表现的要好一些，不过不是太明显。明天再观察一下

关于内存的申请与释放

Mon, 02 Jan 2012 05:52:55 +0000

在C语言中，如果存在malloc，则一定要有free，否则就会产生内存泄露；而且你还不能free两次，否则，程序将直接崩溃。
写PHP程序就比较方便了，你甚至不需要初始化变量，你从来也不用考虑内存回收的问题，但是缺点就是PHP的效率相比C来讲就低多了。

我不知道这种比较是否恰当，我想说的是，有一种内存回收是必须显示地、手动地；有一种内存回收是程序自动探测的。前者效率高很多，但是程序开发的效率就很低了；后者开发效率高，但是程序运行效率低。

后来才发现还有第三种方案：写程序的时候，你不需要显示地、手动地去释放内存，编译器在编译期间会发现什么地方需要释放内存，自动的将释放内存的代码插进去；这样的话，开发效率高了，执行效率也高了，编译的时候慢了一些（我们可能不太关心这个）。从文章 http://www.programmer.com.cn/9436/ 来看，object-c的编译器有这个功能；我想，编译器能做到这种地步，也够煞费苦心的，而且我真的不敢相信编译器不会猜错。