关于iframe的onload事件

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

关于tcmalloc内存分配器

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

关于cookie的secure属性

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

关于浏览器的安全模型

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

关于P3P与第三方cookie

Safari：

设置：

火狐：

设置：

测试脚本：
稍后再补

测试结论：

  • safari
        

              

    1. 不识别P3P协议

      2.         

    2. 默认不接受第三方cookie

      3.         

    3. 对于iframe请求的第三方url设置的cookie不视为第三方cookie； 对于script、img标签请求的第三方url设置的cookie按第三方cookie的设置处理； 对于其他请求，还没有测试

      4.     

  • 火狐    
              

    1. 不识别P3P协议

      2.         

    2. 默认接受第三方cookie

      3.         

    3. 不管是iframe、script、img请求的第三方url设置的cookie都视为第三方cookie

      4.     

        

  • IE    
              

    1. 缺省隐私等级设置为"中"——即"阻止没有合同隐私策略的第三方cookie";换言之，就是支持P3P策略

      2.     

        

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

在统计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个小时

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

关于tcmalloc的学习

这也是一篇关于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表现的要好一些，不过不是太明显。明天再观察一下

 

安装方法：

 

关于内存的申请与释放

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

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

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