<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[Snooda]]></title> 
<link>http://www.snooda.com/index</link> 
<description><![CDATA[Snooda's Blog]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[Snooda]]></copyright>
<item>
<link>http://www.snooda.com/read/</link>
<title><![CDATA[由一个503问题看配置文件重要性]]></title> 
<author>snooda &lt;admin@snooda.com&gt;</author>
<category><![CDATA[lighttpd]]></category>
<pubDate>Sun, 26 Feb 2012 15:55:20 +0000</pubDate> 
<guid>http://www.snooda.com/read/</guid> 
<description>
<![CDATA[ 
	&nbsp;&nbsp;&nbsp;&nbsp;最近有一个困扰近两个月的bug终于解决了，心情愉快。503问题之前一直没找到头绪，压力一大就开始有，越大就越多。刚开始一直认为503是正常现象，后端负载能力不足的必然结果。加之之前后端用的自己写的模拟server，性能什么的没什么保证。所以一直在看是不是程序逻辑上有什么漏洞会导致封禁所有后端，一直找不到头绪。<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;周五测试同学突然说：现在用的后端server肯定能力要强于前边这个啊，怎么可能会因为负载力不足导致503呢？一想确实啊，肯定是流量调度部分的问题。开gdb仔细一找，结果大跌眼镜，原来是跟后端的连接池的最大允许并发连接数开的太小了。。<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;之前那个值设置的比较小是有道理的，因为php是每个进程处理一个请求的，所以并发数肯定不会超过启动的php进程数。但现在后端改用了lighttpd，lighttpd可以承载的并发数是很多的，这样的话在高并发请求的情况下后端连接池很容易就用完了。<br/><br/>&nbsp;&nbsp;&nbsp;&nbsp;由此有两个感触，一是不同场景下配置项一定要仔细想想如何调优。二是bug并不都是逻辑错误导致的，还有可能是配置错了。。。。<br/>Tags - <a href="http://www.snooda.com/tags/bug/" rel="tag">bug</a>
]]>
</description>
</item><item>
<link>http://www.snooda.com/read/#blogcomment</link>
<title><![CDATA[[评论] 由一个503问题看配置文件重要性]]></title> 
<author> &lt;user@domain.com&gt;</author>
<category><![CDATA[评论]]></category>
<pubDate>Thu, 01 Jan 1970 00:00:00 +0000</pubDate> 
<guid>http://www.snooda.com/read/#blogcomment</guid> 
<description>
<![CDATA[ 
	
]]>
</description>
</item>
</channel>
</rss>