对于这两天ruby开发网站性能测试总结

这只是个人测试，也是个ruby初学者的测试，如果因优化不周而造成重大误差还请各位能多多指教。

1. Rails vs Rack vs Merb：
   Rails 性能比Merb差不少，但文档，插件丰富，加上Rack可以高速处理某些需求。又闻Merb要并入Rails，高速处理又有Metal，真是前景无限。
   Rack 一个字快，爽。
   Merb 看上去很美，只是发觉文档太少。不太试合初学者，比如我想让ActiveRecord支持Enum类型，Merb似乎需要自已操刀，而Rails可以拿来就用
   速度上 静态>Rack>Merb>Rails
   速度横向比较
   

   	静态	Rack	Merb	Rails
   速度	3130	1192	305	180

   (单位:reqs/sec)

2. Cache:

   page缓存很方便，而且直接生成html，很容易实现全站静化，只是如果每个文件id都放于同一目录下，很难想像几万文件挤在一个目录下。cache还有待学习。似乎fragment能解决这个问题。
   对于很简单的helloworld，action缓存不快反慢。reqs由180下降到150。

3. 服务器：
   Fastcgi比mongrel快不少。mongrel更易使用。我现在是 development用mongrel，production用fastcgi
   Nginx和lighttpd差不多快，
   apache2的mod_rails性能记得也不错，具体数值忘了，apache2太大型，内存占得多，配置灵活性没Nginx好，且在性能上和Nginx与Lighttpd有不小差距，所以不再予考虑。
4. 我个人最终取向：
   Nginx+Fastcgi+Rails+Rack 作为我的Rails平台。

另外我的blog是  http://www.jiangmiao.org/blog  最近在学ruby中，ruby现在给我最大的感触就是灵活，方便。

 

2009-1-21补充:

1. Fastcgi

   经过实践，发现在fastcgi上lighttpd略胜一筹，最佳的性能稳定Rails平台还是为公认的 Lighttpd+Fastcgi. 但不可否认nginx为非常优秀的服务器，特别是他的配置方式，我尤为中意。

2. Cache

   提到的Fragment Cache与Page Cache为2个不同等级的cache,
   Page提供全文cache，在controller中以caches_page :actionName形式。
   Fragment为区域cache，在views中以 <% cache do %> xxx <%end%> 形式。
   关于Fragment Cache存储方式如文档中提到的

   #内存cache，也是默认的cache
   ActionController::Base.cache_store = :memory_store
   #以文件形式保存
   ActionController::Base.cache_store = :file_store, "/path/to/cache/directory"
   ActionController::Base.cache_store = :drb_store, "druby://localhost:9192"
   ActionController::Base.cache_store = :mem_cache_store, "localhost"
   ActionController::Base.cache_store = MyOwnStore.new("parameter") #重写自已的Store
   

   在environment可以添加语句 config.cache_store = xxx 进行设置

   网上很多文章因使用的rails版本已过时，仍以 fragment_cache_store= 作为教程存在，使人走了不少弯路。所以在rails升级或学习的过程中，阅读changelog是很有必要的。

   关于自定义Store网上教程似乎很少，但因其并不复杂，又因rails源码公开，大家可参考MemoryStore的源文件 memorystore_cache.rb
   如 class MyOwnStore < ActiveSupport::Cache::Store 并重写write,read等方法，则可以轻松制定Fragment的缓存方式。

   关于更多cache可以参考http://www.railsenvy.com/2007/2/28/rails-caching-tutorial 但注意该rails的版本也以过时，因为其log显示还是以Completed in 0.18700 (5 reqs/sec) | Rendering: 0.10900 (58%) | DB: 0.00000 (0%)形式。

FastCGI如果是Rails的话，不推荐搭配nginx，一定要用lighttpd，原因我以前详细解释过了。当然如果你的应用很小，一般也不会碰到问题，用nginx也行。

lighttpd的确比nginx好。
我在测式rack时，500并发，nginx会发生 Broken Pipe错误，不得其解，而lighttpd不会。
但lighttpd在log中会出现一些 "sockets disabled, out-of-fds"
我想Broken Pipe大概源于out of fds.
如此看来，lighttpd在fastcgi方面的确要比nginx更胜一筹

那时因为操作系统默认设置的文件描述符不够用了，你需要设置更大的文件描述符数量，这个可以通过lighttpd的配置文件设置，nginx也应该有类似的设置，这和性能无关。

事实上单纯看静态文件的处理速度、并发支持数量和资源消耗的节省度上来说，nginx要明显好于lighttpd，但在FastCGI支持上，nginx作为一个通用的http proxy，不可能像lighttpd那样专门为FastCGI去实现一些东西。当然你显然没有看过我写的文章。

上面的文章和你的机制是没啥关系。因为我对机制那些不太了解，也没啥发言权。只是站在普通用户，发表一下个人看法。哪个更稳定，哪个更快，支持负荷更高就用哪个。在测rack lighttpd的确要比nginx快，稳。

你的部署文章我已拜读过不下5遍，有log为证，因为我也发觉在fastcgi上lighttpd更有优势，理由可能和你不一样，你是机制怎样，缓冲区怎样等比较深度的比较。而我只是普通用户压力测试的结果。即然都觉得lighttpd好，我也就不去测别的比较到底好多少了。如果发现nginx和lighttpd目前表现还是一样，那我肯定要对你说的缓冲区大小对性的影响，或者进行更苛刻的条件之类进行测试。