易栈网-膘叔

纯记录，原文来自：http://www.cnblogs.com/sunss/archive/2010/12/18/1909779.html

--start--
最近在优化mysql,其中很多人都在配置文件中添加了thread_concurrency,大多数人给出的描述是：

“设置thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的情况下，错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。

thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU, 那么thread_concurrency的应该为4; 2个双核的cpu, thread_concurrency的值应为8.”

具体修改方法是：

[mysqld]

thread_concurrency=8

殊不知，thread_concurrency是在特定场合下才能使用的，参考mysql手册 ：

这个变量是针对Solaris系统的，如果设置这个变量的话，mysqld就会调用thr_setconcurrency()。这个函数使应用程序给同一时间运行的线程系统提供期望的线程数目。

--eof--

但是我没 有看到为什么 是针对Solaris的。。。所以，我就纯记录一下

说起团购，先来一个小插曲，群里的安静说他的同事MM在苏宁前两天的秒杀中，秒杀到了一台IPAD，结果，苏宁把订单给咔嚓了，然后钱也不能退。
其实很明显，我在看到苏宁这个秒杀活动时，以及它的要求后，就很明显的感觉到，苏宁是想推他的那个支付功能，只是我没想到，苏宁是想空手套白狼（猜测而已，因为第一天的订单很多朋友和我说了，明明到02分都还可以秒杀的，但最后出来的订单却是00分的。再仔细看他的规则其实就很明显了。。。。。。）
好吧，开始说我这次不开心的团购经历吧。。
9月17日，我在拉手网上看到了上海苏武牧羊的一个火锅的团购，感觉里面的内容还算是实惠，于是就订了一份。团购内容可以查看：http://www.lashou.com/?id=5127，由于一直没空去吃，而团购券到12月20日就结束。于是就在今天去将它消费掉，但没想到的是，这顿火锅竟然让我非常的不开心。
首先，该团购中的一些优惠活动，事实上已经在正常的营业中提供了优惠，比如标价很高的那个黑毛和牛(一份)  ，现在直接就是优惠为39元。
其次，服务态度也特别差。事实上我提前了两天想预订个位置，但服务员告诉我周五不接受预订。然后排队排了50分钟，而且店内排队优 惠88折拒绝提供（虽然没多少钱，心里太不开心了）。
再次，工号001的的主管态度也非常差。说话的时候板着个脸，仿佛我欠着他很多钱似的。当然，谈了半天，他是一直认为排队的优惠，是属于店内的其他优惠活动，而我的50分钟就是白等了。（然后觉得这位001工号的主管很奇怪，等位卡上写着超过30分钟优惠88折，然后付费的时候，他说不能打折，是因为拉手网上写着不参加其他优惠活动，但等位卡也算是其他优惠吗？然后又说我们没有和他们告知，所以不能打折。好奇怪的想法，为什么不是他在我们点菜的时候就该告知，等位超时打折算是优惠活动？而不是补偿我们的等位时间消耗）
最后，在付款的时候，001号和另外一位穿着同样的女性（看来也算是主管了）在收银台前为了点小事开始争吵，虽然不甚激烈，但让人的感觉十分不爽。还不如那位收银员呢，她说，在客户面前争吵也不知道注意点形象。

总之，这次团购实在让人开心不起来，估计从此之后也不太会参加其他团购活动了，因为不知道是否这种参与团购的商家是否都是那种板着脸的，不是享受而是受气。毕竟，我们不是上帝。
顺便想知道，在中国，有上帝吗？

yii在nginx下的配置好象有点麻烦，搜索一下how to hidden index.php file on nginx，可以搜索到官方的wiki。默认在guide里面是使用apache的，也就是里面的配置是针对.htaccess的。

然后我把官方wiki的内容复制到了nginx.conf里，却一直发现不成功，所以，只有等 明天再试了。
问了烂桔，他说的方法和官方的wiki里不太一致。在index.php后面没有$1，所以准备明天试一下。。
官方原文在这里：http://www.yiiframework.com/wiki/15/how-to-hide-index-php-on-nginx/

烂桔说，官方的这个：

location /yiiGuestbook {
    if (!-e $request_filename){
        rewrite (.*) /yiiGuestbook/index.php/$1;
    }
}

可以改成：

location /yiiGuestbook {
    if (!-e $request_filename){
        rewrite ^/(.*) /yiiGuestbook/index.php last;
    }
}

事实上，我在测试的时候，nginx的检测配置里好奇怪，如果我写 if(!-e xxx)，这样就报错，非要if 后面加一个空格 。还要(后也有空格。不然就报 !-e 是语法错误 。。
明天再测试 一下

以下遇到的问题我没有遇到过，不过我经常用IE6打开网站后，突然间就显示该页无法显示，不知道是否类似原因 。。。

症状【并非我自己的问题】：最近发现自有产品的试用系统有些页面在提交时无反应，等了很久之后显示“Internet Explorer 无法显示该网页”错误；类似的还有一些链接点击之后无反应，等了很久之后显示“Internet Explorer 无法显示该网页”错误。更为离奇的是：

1. 这个错误无法在开发电脑上重现，试用完全相同的程序和数据，在开发电脑上就完全不会出现错误。
2. 使用IE8访问出错，使用IE6或IE7访问时偶尔出现错误，而使用Firefox和Chrome则完全不出错。

牛刀小试

尝试一：是不是IE浏览器脚本兼容性问题？

错误只发生在使用IE浏览器的情况下，是不是IE浏览器和页面上的脚本不兼容造成的？在开发电脑上无法重现错误，可能是因为局域网内使用IE8访 问，实际是运行在IE7模式下，在IE7只偶尔出现错误，因此无法重现。基于这个假设，开始尝试找出是什么脚本导致错误，首先怀疑IE8的XSS过滤机 制，手工关掉IE8的XSS过滤，错误依旧。仍然不死心，也许XSS很顽固，没有真正关掉。所以又将QueryString传递的参数进行编码解码，避免 被浏览器误认为存在XSS攻击，还是没解决。

尝试二：是不是IE浏览器无法处理长路径？

老是怀疑IE浏览器也是有原因的，因为使用Firefox和Chrome时完全不出错，各种证据下IE的嫌疑最大。出错的页面和链接都有一个共同的 特点就是页面的路径比较长，大都在500字符以上，因此怀疑IE8浏览器处理长路径是不是有问题。通过调整程序缩短了页面路径后，错误暂时解决，但仍然有 几个疑点尚未弄明白：

1. 为什么IE8必然出错，而IE6和IE7只是偶尔出现错误？
2. 为什么在开发电脑上无法重现错误？同样是使用IE8浏览器访问，页面路径长度相同。为了尽可能模拟访问外部服务器的情况，特地修改了本机hosts文件，采用与外部服务器完全一致的域名来访问，仍然不会出现错误，为什么会这样？

重新分析问题的真正原因

上面虽然没有找出问题的真正原因，但也还是有两个收获：通过尝试一可以排除XSS方面原因，而通过尝试二发现了这个错误与页面路径长度有一定的联系。

这个错误仅出现在IE浏览器上，是否是IE浏览器发生错误，导致请求没有发出？通过Fiddler侦听发现，请求其实是发送出去了，但一直没有收到服务器的响应，因此将怀疑的目标转移到服务器上。

在服务器上通过分析IIS日志，发现IIS并没有收到请求，反复测试确认，在服务器上确实没有收到请求。

浏览器发出了请求但服务器端没有收到请求，那么问题一定就出在传输环节，这时突然想起机房前段时间搞了一个白名单过滤系统，问题是不是就出在这个白 名单系统上。如果真的是机房的白名单系统出了问题，那么之前的很多疑团就可以解释清楚了。比如：本地无法重现，是因为本地并没有白名单系统；浏览器发出了 请求，而服务器端没有收到，是因为白名单过滤系统将请求过滤掉了；白名单过滤系统有BUG，导致IE浏览器的长路径请求无法正确处理，而被错误过滤等等。

分析了这么多，疑点都集中到机房白名单过滤系统（以下简称白系统）上，但终归只是猜测而已，还需要更确切的证据来证实。机房不会配合我来调查，更不会透露关于白系统的任何细节（这种系统见不得光），唯一的办法就是找到白系统出错的规律，通过反证的方式来找出证据。

黑盒分析白名单过滤系统

设想一下，如果让我来写一个白系统的话，应该这样来实现：过滤所有的HTTP请求头，分析请求头中的Host属性值（主机头+端口），如果该主机头 在白名单里，则允许通过，否则不允许通过。HTTP请求头可能很长，白系统不需要全部读完请求，只要读取到Host属性值即可。为了提高过滤效率，当 HTTP请求头很长时，白系统可能只读取分析开始的N个字节长度内容，剩下的内容就被丢弃，不进行分析。在这种情况下，如果开始的N个字节长度内没有找到 Host属性值，则该请求就会被白系统过滤掉。

所以白系统是根据HTTP请求头中的Host属性值来进行过滤的，IE浏览器的HTTP请求头格式与Chrome的Http请求头格式不同，特别是 Host属性的位置不同。IE浏览器中Host属性的位置靠后，大约在第七位；而Firefox和Chrome中Host属性的位置靠前，大约在第二位。 当页面路径很长时，Http请求头就会变得很大，这时候如果Host属性在Http请求头中的位置比较靠后，就可能超出了白系统的固定读取的N个字节的范 围，导致该请求被忽略。下面列出几个浏览器的Http请求头内容，供参考：

Chrome的Http请求（Host在第2行）

Firefox的Http请求（Host在第2行）

IE的Http请求（Host在第7行）

用Fiddler生成Http请求头来测试，并不断调整Host的位置，最终测试出漕宝机房白系统的读取长度为1470字节。如果Http请求头开 始的1470字节内没有包含Host属性的话，白系统会丢弃掉该请求，造成服务器端收不到该请求，客户端也因为收不到服务器端的响应而显示 “Internet Explorer 无法显示该网页”的错误。

一般来说，网页的Http请求头都不会太大，有些也只是最后的Cookie内容多一点，不会影响白系统的运行。但我们开发的这套企业管理软件的某些 页面使用QueryString方式在页面间传递参数，这样可能导致页面的url地址很长，虽然我们控制了url地址的最大长度（小于1024），但没有 想到这个长度已经超过了机房白系统的处理范围。

特别是页面回发的情况下，请求头中会包含两次Url地址（请求地址和Referer分别一次）。假设url地址有1000字节，Firefox和 Chrome的Host属性在第二位，从开始读取1470字节的话，一定可以读取到Host属性值。而IE则不行，Host属性前面还有Referer属 性（长度1000字节），加上页面路径本身有1000字节长度，Host属性前至少有2000多字节，所以白系统只读取开始的1470字节，是不可能读取 到Host属性，因此请求被白系统过滤，造成客户端点击按钮提交后长时间收不到响应，最后显示“Internet Explorer 无法显示该网页”的错误。

题外话-关于白名单过滤系统

为了提高过滤效率，机房的白名单过滤系统大都采用监听加干扰的方式，一旦发现某客户端有非法请求，就先于服务器给该客户端一个错误的响应，这种情况 下，客户端会很快显示错误信息。但这次的白系统似乎是采用水闸大坝的方式实现（这种方式很低效，以后要考虑换机房），发现非法请求后就丢弃该请求，导致客 户端长期等待响应，最后等待超时，才显示错误。正是这种长时间的等待，才误导我一开始就怀疑是浏览器的问题。

--EOF--

这个问题我没有遇到过，不过我想或许可以参照一样。。。原文来自：http://www.cnblogs.com/rrooyy/archive/2010/12/09/1901304.html，我从没注意过原来host的顺序还会影响网站的访问（白名单这个问题确实很让人痛苦。以前我的SERVER还被edong装过一个组件，用来处理白名单）

最近也正在做shopnc的重构，当然也就有自己的想法喽。偶尔看到这篇文章，乐死，估计所有重构过代码的人都会有类似想法吧。

原文来自：http://www.cnblogs.com/XmNotes/archive/2010/12/13/1904377.html

我在这里，就列举一下Refactorman的种种死法，以警后人：

一、一边重构，一边要完成日常任务……

1. 疲于奔命，过劳而死。

2. 吃领导给的鸭梨太大被噎死。

3. 满脑子都是代码，在上班路上不留神撞上了宝马。

4. 冷落了女友，受失恋打击跳楼而死。

5. 无暇社交，不懂人情世故，失意而死。

6. 为了说服领导和同事，心力交瘁而死。

二、重构过程中……

7. 被以前的混账代码气死。

8. 被混账代码搞得大脑程序溢出，彻底崩溃，神智错乱而死。

9. 终于醒悟，问题只是冰山一角，力有未逮，忧愤而死。

10. 泥足深陷，举步维艰，进退维谷被活活困死。

11. 自己昏天黑地，看其他同事却吊儿朗当，逍遥快活，心理不平衡致忧郁而死。

12. 重构过程中，踩中前任留下的地雷，被炸得体无完肤而死。

13. 一日偶遇以前代码的作者，怒不可遏，将其一通乱砍，再鞭尸三百，然后切腹而死。

三、经九九八十一难，大功告成……

14. 系统重构后性能提高了？漏洞消除了？对不起，领导们没兴趣，失落而死。

15. 系统重构后出现了新Bug，多半会小题大作，遭游街批斗而死。

16. 马上接到通知系统功能要大升级，吐血而死。

17. 同事依旧我行我素，继续在系统中倒垃圾代码，痛心疾首而死。

18. 重构将系统中的阴暗面曝光，被同事记恨，领导排挤，学屈原投江而死。

19. 过了不多久，发现系统又乱成了一团，比以前好不到哪儿去，悲愤下一头撞死。

20. 离职后偶遇前公司的新任维护者，被其乱刀砍死再鞭尸。

　　各种死法中，最后一种，我们比窦娥还冤枉。所以强烈推荐大家还要练一门武功以防身。什么武功，就是：“心惊肉跳、杞人忧天、无中生有、力不从 心、行尸走肉、庸人自扰、倒行逆施、废寝忘食、孤形只影、想入非非、呆若木鸡……”。这门传说中的黯然销魂掌，其中一招一式，正是我们最好的写照。