<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/2.0.10" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>听松一隅</title>
	<link>http://blog.quehy.com</link>
	<description>ALaRechercheDuTempsPerdu</description>
	<pubDate>Wed, 01 Jul 2009 03:53:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.10</generator>
	<language>en</language>
			<item>
		<title>mod_fastcgi fair load distribution patch</title>
		<link>http://blog.quehy.com/archives/213.html</link>
		<comments>http://blog.quehy.com/archives/213.html#comments</comments>
		<pubDate>Mon, 29 Jun 2009 05:05:41 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/213.html</guid>
		<description><![CDATA[当前mod_fastcgi请求分配算法是只考虑fastcgi进程当前请求数，没有考虑累计请求数，因此前几个fastcgi进程会特别忙，后面fastcgi进程非常闲
打完补丁，重新编译，在lighttpd.conf中加载module mod_status，设置 status.statistics-url = &#34;/lighttpd_status&#34;。然后访问http://ip/lighttpd_status 可 mod_fastcgi状态
补丁下载地址

]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/213.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>lighttpd &#038; modcache ppt</title>
		<link>http://blog.quehy.com/archives/212.html</link>
		<comments>http://blog.quehy.com/archives/212.html#comments</comments>
		<pubDate>Sun, 28 Jun 2009 15:07:55 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/212.html</guid>
		<description><![CDATA[讲座ppt下载。
1) squid和modcache的对比：squid是个功能全面的系统、但效率不高；modcache是功能不多，但效率高的缓存系统；请求数不多的情况下 (1k req/s)的情况下，CPU也不忙，比Squid好太多；也就是说lighttpd不属于CPU计算量大的程序，而大部分时间在处理、等待网络IO，磁盘IO
4) keepalive 尽量关闭。lighttpd 1.4.23新加的server.defer-accept选项不错，可设置成server.defer-accept=30
5) 小文件缓存到内存；大文件放硬盘，硬盘没必要用raid
6) 加载 mod_status，设置 status.statistics-url = &#34;/lighttpd_status&#34;。然后访问http://ip/lighttpd_status 可看到modcache 的缓存命中率
7) modcache 使用两级hashmap管理内存缓存，效率不错，支持上千万的项目快速存取
8) 单进程和多线程。单进程适合现代的硬件和软件；多线程的弱势在于锁：一般多线程使用多个全局锁，当请求数量超过一定值后，全局锁会导致性能急剧下降；多线程的扩展性比单进程差不少。
多线程适合不同线程做不同工作，或者请求数量可控、且不高的情况
9) nginx 和 lighttpd对比
i) nginx 各模块结合比较紧密，效率比lighttpd高些
ii) nginx 代码更新频繁，比lighttpd好不少
iii) nginx 强项是做proxy，而且proxy种类也比lighttpd多，实际也见到不少这样的使用案例。
一般使用 lighttpd 和 nginx 差别不大，具体用哪个看个人偏好
]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/212.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>6月28日 14:30 奇遇花园咖啡馆 lighttpd&#038;modcache 免费技术讲座</title>
		<link>http://blog.quehy.com/archives/210.html</link>
		<comments>http://blog.quehy.com/archives/210.html#comments</comments>
		<pubDate>Fri, 12 Jun 2009 03:38:53 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/210.html</guid>
		<description><![CDATA[应火炬的邀请，6月28日（星期天）下午2:30我将在 第五期 beta技术沙龙上做 lighttpd和modcache的技术讲座，内容丰富。
地点是西直门旁的奇遇花园咖啡馆，现场可容纳不超过100人。
讲座后还有Q&#038;A环节，欢迎有兴趣的童鞋来现场捧场，就lighttpd和modcache的方方面面提问、交流。
讲座免费，无需提前报名，直接到讲座地点听即可
奇遇花园咖啡馆地理位置



]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/210.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>modcache v1.8.0 released</title>
		<link>http://blog.quehy.com/archives/209.html</link>
		<comments>http://blog.quehy.com/archives/209.html#comments</comments>
		<pubDate>Sun, 07 Jun 2009 04:05:36 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/209.html</guid>
		<description><![CDATA[modcache v1.7.0 发布后，在使用过程中感觉到压缩内容的处理不大顺畅。因此发布v1.8.0版本，以改进压缩内容的处理逻辑
处理逻辑的改动：

v1.7.0的gzip输出功能是需要后端服务器的支持，v1.7.0会区分后端服务器提供的压缩和非压缩内容，但自己并不做压缩
v1.8.0中改成由modcache做内存缓存的压缩，而本地文件的压缩可由mod_compress提供，后端服务器不需要压缩输出内容

具体配置的改动：

删除 'support-accept-encoding' 和 ‘try-gzip-deflate-only' 两个选项
增加 'memory-compress' 和 'ignore-vary' 两个选项

'memory-compress' 选项就是压缩内存中缓存的未压缩内容，当客户端发出带&#34;Accept-Encoding: gzip, deflate&#34;这样的请求时，modcache会输出gzip压缩后的内容，以达到节省带宽的目的
'ignore-vary' 选项让modcache忽略后端服务器中的“Vary”输出。根据RFC，当后端服务器输出带“Content-Encoding: gzip”的内容时，应该同时输出&#34;Vary: Accept-Encoding&#34;。但有部分http server 在不带“Content-Encoding: gzip”时也输出“Vary: Accept-Encoding&#34;头，此时就需要这个选项忽略它
下载地址

]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/209.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>modcache v1.7.0 released</title>
		<link>http://blog.quehy.com/archives/208.html</link>
		<comments>http://blog.quehy.com/archives/208.html#comments</comments>
		<pubDate>Tue, 05 May 2009 03:35:51 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/208.html</guid>
		<description><![CDATA[modcache 1.7.0 新增加的重大功能是可以把缓存存到内存里，而不只是本地硬盘。这个功能适合缓存小文件，比如小图片，JS，CSS，html文件。实际系统运行对比squid的nullfs，性能提高了5~10倍，还是不错的。
新增加的配置项是：

cache.max-memory-size，单位是Mbytes，缺省是256（256M内存）。modcache使用的内存缓存不会超过这个数值
cache.lru-remove-count，缺省是256。这个参数基本不用动

原来的cache.support-accept-encoding选项被取消了。
refresh-pattern也增加了三个选项：

use-memory：用内存作为缓存空间
support-accept-encoding：支持缓存压缩后的内容
use-gzip-deflate-only：对于带“Accept-Encoding&#34;的请求，如果没有压缩后的缓存内容，则modcache不吐未压缩的内容，而把请求传递到后端服务器；

举例：
一: 图片缓存服务器

cache.max-memory-size = 2000 #maxium 2000M
cache.refresh-pattern = (
        "\.(?i)(jpg&#124;bmp&#124;jpeg&#124;gif&#124;png&#124;ico)$" => "0 use-memory",
        "." => "120 no-cache"
)

二：页面缓存服务器

cache.max-memory-size = 1500 #maxium 1500M
cache.refresh-pattern = (
        "\.(?i)(jpg&#124;bmp&#124;jpeg&#124;gif&#124;png&#124;ico)$" => "0 use-memory",
       [...]]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/208.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>lighty reloaded, improved</title>
		<link>http://blog.quehy.com/archives/207.html</link>
		<comments>http://blog.quehy.com/archives/207.html#comments</comments>
		<pubDate>Thu, 12 Mar 2009 18:56:47 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/207.html</guid>
		<description><![CDATA[花点时间把之前做的几个lighttpd 模块代码整合到一起，并在googlecode上建立了主页，第一版发布整合了mod_cache和mod_mem_cache两个模块，未来会整合其他模块
发布第二版，增加mod_mem_compress module
mod_mem_cache和mod_mem_compress都可使用共享buffer，可以大大减少内存分配、释放的次数
]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/207.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>原创 - 轻松制作可启动U盘</title>
		<link>http://blog.quehy.com/archives/202.html</link>
		<comments>http://blog.quehy.com/archives/202.html#comments</comments>
		<pubDate>Sat, 11 Oct 2008 12:33:59 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/202.html</guid>
		<description><![CDATA[以前一般是用USBoot工具来制作可启动U盘，成功率不高，而且不支持大容量U盘。最近把16G U盘做成启动盘，特把经验总结出来共享
用到的工具：

HP USB格式化工具
GRUB4DOS 工具
启动盘

下载以上内容后，把U盘插入电脑。
步骤一：解压grubinst.rar，运行grubinst_gui.exe，安装grub4dos到U盘。

步骤二：winrar把bootdisk.rar的内容解压到U盘根目录。

到此可启动U盘就制作完毕，拿U盘去启动电脑吧。

如果U盘不能启动，可以用hp USB格式化工具格式化U盘。

再重复上面步骤

Bootdisk的内容：

IBM Hardware Maintaince Disk 1.75
Hitachi Feature Tool
Ghost 11.02
Ghost 8.3
Active Boot Utility Disk 4.0.1
Partition Table Doctor 3.5
R-Studio Emergency 3.8
Paragon Partition Manager 9.0

感谢强大的GRUB4DOS和GRUB
]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/202.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>一个有意思的lighttpd 1.4 内存泄漏</title>
		<link>http://blog.quehy.com/archives/201.html</link>
		<comments>http://blog.quehy.com/archives/201.html#comments</comments>
		<pubDate>Sat, 20 Sep 2008 12:09:32 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/201.html</guid>
		<description><![CDATA[上个月几台跑lighttpd 1.4.19 + mod_fastcgi + php 5的服务器，出现莫名其妙的内存泄漏，一天泄漏几百兆内存。这个现象之前都没出现过。既然是跑mod_fastcgi，那就从mod_fastcgi开始查起吧，但查了几天也没有线索。
后来就用tcpflow抓服务器请求的情况，发现有很多请求中有两行“Range: ”，猜想它也许是这个。然后把抓到的带两行“Range:&#34; 请求做测试，就找到导致内存泄漏的原因。
原来是lighttpd在请求分析步骤中，发现有重复的请求行，会报HTTP 400错误返回，但返回之前没有释放刚分配的内存。每次错误的请求导致大概64 bytes的内存泄漏，正好那些天错误请求每秒有好几十个，导致每天要泄漏上百兆内存，呵呵
补丁下载，此补丁也提交到lighttpd ticket系统
]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/201.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>magent</title>
		<link>http://blog.quehy.com/archives/200.html</link>
		<comments>http://blog.quehy.com/archives/200.html#comments</comments>
		<pubDate>Sun, 07 Sep 2008 08:48:56 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/200.html</guid>
		<description><![CDATA[magent is a simple but useful proxy program for memcached servers. 
People uses php/java client to connect to memcached server, may find following problems:

lack of keep alive connection between client and server
no hot backup servers
no healthy check

Here magent emerges, try to resolve these problems.
visit magent homepage for more detail
]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/200.html/feed/</wfw:commentRss>
		</item>
		<item>
		<title>谈谈异步IO(AIO)</title>
		<link>http://blog.quehy.com/archives/199.html</link>
		<comments>http://blog.quehy.com/archives/199.html#comments</comments>
		<pubDate>Mon, 24 Mar 2008 15:03:52 +0000</pubDate>
		<dc:creator>Q</dc:creator>
		
		<category>Tech</category>

		<guid isPermaLink="false">http://blog.quehy.com/archives/199.html</guid>
		<description><![CDATA[对于类似ligthy的事件(event)驱动的server，某个阻塞操作会大大降低程序的效率。文件读取操作通常是最容易堵塞的地方；而异步IO(AIO)貌似是解决文件堵塞的灵丹妙药。
大概三个月前，花了点时间在lighttpd 1.4.18上实现了AIO的支持，也是了结一个心病。由于原来的LINUX AIO计划早已停止，我拿POSIX AIO for LINUX 做实验平台，补丁也移植到比较新的2.6.23上。
拿ab测试，发现AIO的大文件吞吐性能很差，不到linux sendfile的一半，系统负载却大很多；让人感觉不可思议，怎么会这样呢？印象中lighty 1.5的aio测试效果还不错的。仔细拜读lighty 1.5的aio 代码，才恍然大悟：
1) AIO不支持sendfile。纯AIO实现 需要把文件内容读到内存中，然后再写到网络层上。为了不占用大量内存，一般是按1M或几M大小依次读取文件内容。AIO可以在读取完毕后通知服务程序，避免阻塞；但内容读取到用户内存中再写到网络层的效率很低
2) Lighty 1.5为解决上面的问题采取了两个办法，第一是多线程；第二是不到万不得已的情况不用AIO，大部分是用mmap/sendfile的。
再拜读Posix AIO规范说明，发现AIO原本意图是解决实时系统中文件操作堵塞的问题。实时系统中文件一般不大，文件操作也不频繁，AIO就比较合适。而在web服务中，适合AIO的前提条件并不存在，因此效果不佳也正常。POSIX AIO定义的操作也不多
最后写三点感想：
1) 完成某个工作的，可以用到的工具(开源项目)很多，选择时要对备选的工具多考察，选择最适合的，而不是看起来最美的
2) 功能不是越多越好，保持代码简洁、系统框架简洁很重要。比如我个人认为ligthy 1.5中引入glib库是个败笔
3) sendfile 很好。对它的多年优化工作可不是白费的

]]></description>
		<wfw:commentRss>http://blog.quehy.com/archives/199.html/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
