夏海霞的网络日志

发了这么多次的版本，还是第一次这么悲剧的扯了这么长时间，虽然距离这个悲催的日子已有段时间，为了纪念，有必要记录一下，以免下次再犯。

用httpwatch监测发现，部分请求回来为502 bad gateway，运维发现，请求还没有到达服务端就已经错误返回了。运行一个简单的php文件，那还都是正常的，让其重启，发现问题依旧啊，后来换了个运维，重启之后竟然正常了，╮(╯▽╰)╭。

网上查看，php-fpm的默认静态处理方式会使得php-cgi的进程长期占用内存而无法释放，这也是导致nginx出错的原因之一。

据分析

with the help of memory_limit to 256M, max_execution_time=300s
and fastcgi_read_timeout=240s 查了下原因可能是上面三个
不过我刚只重启了下php，没改配置，php-fpm可能假死了。

资料详情：

我的VPS是256M的内存，CPU是四核心的，所以更多的我会在乎内存。而在我调试服务器的时候通常会遇到Nginx502 bad gateway和504 Gateway Time-out的错误。分析nginx.conf我发现server和fastcgi的buffers过多，导致fastcgi请求的数量过大，php-fpm无法及时处理而出错。循此思路我们可以再总体buffers不变的情况下减少请求数量，具体的ningx.conf改动细节如下：
程序代码                server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 1 128k;# 4 32k
client_max_body_size 8m;

sendfile on;
tcp_nopush     on;

keepalive_timeout 60;

tcp_nodelay on;

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 128k;
fastcgi_buffers 2 256k;#8 128
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_errors on;

gzip on;
gzip_min_length  1k;
gzip_buffers     1 64k; #4 16
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types       text/plain application/x-javascript text/css application/xml;
gzip_vary on;
另外，php-fpm的默认静态处理方式会使得php-cgi的进程长期占用内存而无法释放，这也是导致nginx出错的原因之一，因此可以将php-fpm的处理方式改成apache模式。
程序代码<value name=”style”>apache-like</value>
从更改完毕到现在的测试表明上述方式的效果还是很明显的，并没有发现一次Nginx502 bad gateway或504 Gateway Time-out错误。当然，如果你的VPS或者服务器的性能足够好可以根据具体情况不必做无谓的改动。

http://www.ntsafe.com/html/jishuziliao/caozuoxitong/20100113/97.html

前言：setTimeout与setInterval是window对象的两个非常神奇方法，用于实现定时或延时调用一个函数或一段代码。
（有人可能认为setTimeout与setInterval是javascript函数，这是错误的。这是将javascript对象函数与DOM对象方法混淆所致。）

本机windows环境，在apache非根目录下安装了wordpress3.2中文版本，上传图片时出现提示“上传的文件无法转移到...”，因为是win环境，所以肯定是非权限问题，仔细注意图片，发现图片的名字是中文名，换了个英文名就可以上传了，不过本blog更新到3.2版本，没有发现这种情况，中文名图片照样正常上传。等有空的时候看一下具体源码实现。

本来没打算写这篇的，但是每次被别人莫名的错误说是因为我们项目导致的，就会莫名的恼火。这年头推卸责任的人可真多，不追究根源的也不少。

因为document.domain的原因引起编辑器错误的产生，我脑中第一个就想到了document.designMode，于是好好整理了一下。

实现可视化编辑，可以使用contentEditable和designMode两种方法。contentEditable刚开始在IE上实现，后来各大 浏览器陆续支持contentEditable，HTML5标准也包含contentEditable。designMode只能把document整体 改成可编辑状态，但contentEditable可以把任何HTML元素改成可编辑状态，应用范围比designMode广，用 contentEditable是将来的趋势。

但在IE上designMode和contentEditable不完全一样，有不少细微的差距，我们开发可视化编辑器时需要格外注意。

1. 在IE上使用designMode，调用document.domain将报没有权限的错误，用contentEditable没有此问题。

2. 在IE上使用designMode，右键菜单没有复制、粘贴功能，出来的是普通网页的右键菜单。

3. 在IE6和IE7上使用contentEditable，在某些情况下焦点自动移动到编辑区域，类似focus()的效果。这个问题非常要命，因为很多时候我们不希望页面初始化时焦点跳到编辑区域里。

所以针对以上原因建议是IE下将页面设置成可编辑状态是document.body.contentEditable = true;非IE的浏览器是document.designMode="on";

参考链接：http://luolonghao.javaeye.com/blog/693814

http://ued.alipay.com/wd/2008/11/08/js%E8%B7%A8%E5%9F%9F%E8%AE%BF%E9%97%AE%E6%93%8D%E4%BD%9Ciframe%E9%87%8C%E7%9A%84dom/