对SCGI/Mongrel的作者的访谈(关于Rails企业级应用、放弃SCGI等的言论)
去年5月份翻译的，温故而知新。大半年后会发现，Mongrel的目的达到了。
英文原文出处：
http://www.oreillynet.com/ruby/blog/2006/05/post.html
翻译：
alang (http://my.donews.com/alangs)
Zed Shaw 是一个在Ruby世界中声名鹤起的开发者，它是Mongrel(一个Ruby的web服务器)的作者，因快速、稳定、安全而出名。在这个访谈中，他讨论了Mongrel,Ruby,和他的创建良好代码的经验。
问：你是怎么来到Ruby世界中的？
答：多年前，我在开发一个怪异的控制工具－－我叫它FastCST时－－接触到Ruby时。我试了一下Ruby,但是不得要领，马上就回到了C语言了。当 我读了Curt Hibbs的文章时，才了解到，Hey,他们在用这个东西在做领域语言（domain specific languages ）。从那时起，我就开始开发一个Ruby版本的FastCST，然后我对这件事厌烦了，因为同时还有其它的几个Rails项目。
问：许多人都在说，Ruby和Rails不适合做“企业级应用“ ，你怎么看这个问题？
答：在回答这个问题之前，我必须要明确人们所谓“企业级应用”的定义，可以概括为三点：
１、庞大、昂贵
２、可扩展性，性能，满足我的服务需求
３、法律上有保障的商业技术支持，用以掩盖潜在的失败。
问：Okay,让我们一点一点的来谈，Ruby和Rails都是免费的，它们怎么得到花费昂贵（的人们）的认可？
答：他们的定义，企业级应用意味着你要花费上百万的money在硬件和软件上。这么多年来，他们一直在灌输这个观点，是因为他们要从中得益。实际上你的解决方案要符合你的真实需求。如果你需要一个庞大的解决方案，是因为你并没有真正了解你到底需要什么。
Rails在解决这些问题时，并不需要你花费那么多的资金。
问：那么，Rails的可以扩展性呢？
答：那些企业级应用中的“扩展性”，我都可以用Mongrel来解决。首先，要把可扩展性与高性能要区别开来，同时要回到资源的可以扩充性上来。一旦你把这二者区分开来，你就能得到一个两者旨顾的正确答案。
Rails的扩展性（指的是满足需求的可扩展性），和其它的Web应用框架一样好。Mongerl让这个工作变得非常简单，它非常快，基于HTTP。如果 你以前用过Tomcat,Resin,WebLogic或者Apache+PHP，那么Mongrel运行Rails会达到同样的效果。
其实我是承认Ruby的效率不高的。Ruby的社区曾经有意的忽略了“高性能”这个房间里的大象，他们必须正视这一点。现在已经有了一些成果，让ruby 变得快一些。但是还有许多问题要解决。有一个叫YARV的虚拟机已经展示了一些成果，(对Ruby)的加速已经可以和java的解决方案(jRuby?) 相提并论了。
Ruby的闪光点不在于它的运行速度，而是在于它的开发速度。我可以证明这一点，我在Mongrel上花了三个月的时间，它已经是一个全功能、稳定、高效的web应用服务器，可以用它来支撑许多Ruby站点。如果不用Ruby，这个开发进度是不可想像的。
Rails的问题又不同于Ruby，因为Rails自己有着优秀的缓存机制，这在一定程度上弥补了Ruby的“龟速”。Rails用"page caching"、"fragment caching"来加速应用。如果你善用这个功能，良好的规划你的缓存方案，你可以得到和静态页面一样的网络性能。甚至比Java或者PHP的做得还要 好。
问：那么，商业化的技术服务呢？
答：Rails现在还做得不够好，但是，情况会越来越好。会有越来越的资金投入到这个(Rails)服务领域来的，他们会像PHP类似的众多服务一样做得很好的。如果你看看PHP，最开始只有Zend一家在做这个服务，后来有越来越多的大公司加入到服务的行列中来。
问：在开始做Mongrel之前，你在开发SCGI，说一说它们之间的相似之处，谈谈他们如何协作，或者不协作？
答：SCGI(http://www.zedshaw.com/projects/scgi_rails/) 是我的第一次替代FastCGI(http://www.fastcgi.com/)的尝试。SCGI的目的是高效的支撑纯Ruby应用，目的已经达到 了。但是，SCGI在多web服务器中的支持是有限的。并且不是将来开发的选择。Lighttpd的支持发源于对它的mod_fastcgi的突兀的修 改。Apache的SCGI模块来自于Apache项目之外，并且Apache项目着重声明过对FastCGI的支持要多过对SCGI的支持。事实证明了 许多人在Apache上使用SCGI都遇到了麻烦，特别在与多个后台通信时，SCGI看上去不妙。
Mongrel最开始是作为一个SCGI的代理，来试图解决这个问题。我写了一个Http的解析器，然后用C写了一个代理程序来响应请求，再转发给 SCGI。做到一半的时候，我意识到这个解析器写的是如此的完美，让我决定跳过中间部分，直接写用Ruby写一个web服务器。大约一天之后， Mongrel诞生了。
我的对SCGI的计划是，简化它，只满足最基本的要求。SCGI里面目前有许多的DRb(分布式Ruby)管理代码，还有一些其它人使用(滥用)的片断， 但是，这对那些只是希望使用SCGI来工作的人来说没有一点用处。为了支持那些目前使用SCGI的用户，我将移植一些Mongrel的发明过去，比如 thread模型。要简化SCGI，让它回到最初的面目上去。
说了这么多，我想你已经明白了我未来的工作主要是Mongrel，我认为它是支持Ruby web应用的比较power的方法。
如果有任何人对接手SCGI的工作感兴趣，我欢迎。它在RubyForge上有个项目主页，有兴趣和有能力的人来吧，我已经准备好了交出它的管理权。
问：你在Mongrel上的工作是如何影响你在Rails上的工作的？或者相反？
答：在Mongrel中，我必须用到的Rails代码非常的少，这是为了让Mongrel与Rails保持比较松散的偶合，这样当他们（Rails）在某个release版中改了什么东西并且让程序崩溃时，Mongrel不受影响。
当我在用Rails上开发时，我积极的使用Mongrel，并且记下哪些方面要作改进。这让我可以保证Mongrel的实用价值，而不是为了纯粹的学术目的作的凭空想像。
举个例子，我在windows平台上做开发，那简直是不可思义的痛苦，主要的原因不在于windows本身，而是开发Rails的人（DHH之流），从来 没有深入的使用过windows（原话：从来没有走进过windows电脑五英尺）（译注：DHH等人整天的show他们的Apple笔记本，什么时候想 过windows用户）。Luis Lavena做 的许多改进让事情变得好了些。对于我这样的、还有其它许多贫穷的使用windows的粗人来说（是啊，相对于用Apple电脑的人来说，我也好穷啊。但也 不是粗人吧），我要让Ruby on Rails更容易使用些。 （深得我心啊！在Mac平台上开发Rails无疑是绝佳的体验，但，我买不起MacBook！）
问：我知道你在为Rails和Nitro camps上能运行Mongrel而努力。目前最大的障碍是什么？
答：最好的事情是让Mongrel变成框架无关的。我是唯一的一个能让Rails与Mongrel协作的人。Rails核心开发团队的一些家伙主要是在开 发时测试Mongrel，但是我自己，Luis Lavena，其他的几个人，几乎做了让Mongrel产品化的全部工作。我和Luis是唯一被期待用Rails来做产品的人。（译注：说到这里，Zed 好像有些愤愤不平的情绪在里面）
Nitro，camping，还有IOWA团队的人，为我做了许多（mongrel适应）他们平台上的工作。他们下载Mongrel，阅读文档，初期会打扰我，但是大部分时候不要我插手。
我觉得我帮助Campng项目最多，但实际上管理Mongrel的代码要归功于Camping。它回馈给我的是一个大文件的上传/下载补丁，这个补丁放在了0.3.12.5发行版中。因为他说他是在给ParkPlace做DVD的上传/下载时碰到了。（这下对Mongrel做下载类的网站放心了）
问：Mongrel给那些使用它的项目们回报什么了呢？
答：我认为有两件最大的回报，一是安全性增强，二是win32平台的支持。
Mongrel的设计考虑了大多数HTTP服务器碰到过的安全问题，这些问题来自于过于散漫的HTTP协议手工代码处理。Mongrel使用了一个生成处 理器（使用了Ragel：http://www.cs.queensu.ca/home/thurston/ragel/）,它非常稳固、优秀，可以阻挡 大量的网络攻击。因为这个保护是来自于HTTP协议层的，所以使用Mongrel的任何框架都可以免费的使用它。
在EastMedia/VeriSign项目中，我们遇到了一波来自某“安全公司”的网络攻击。在这里我不想指出这家公司的名字，以免给他们做了免费的广告。他们在没有事先通知我们的情况下，对还没有发布的机器，使用了一些扫描软件。
好在Mongrel在HTTP协议层阻挡了所有的攻击企图，没有费一点事就把他们踢了出去。但是就在同时，Apache却让这次攻击通过了代理服务器，一点报警都没有。
当他们进行了自动扫描之后，我们知道了有一些在安全公司的手写代码攻击的人，被Mongrel所做的深深吸引住了。
最有趣的部分是，Mongrel所做的全部，是使用了一个基于文法和解析生成器(Ragel)的正确的解析器。其它web服务器使用人工编写的HTTP解 析器，被证明是易受攻击的、难于与真正的HTTP1.1 RFC规范相比较，维护起来也是非常痛苦的。使用了Ragel之后让Mongrel非常的稳固，不需要创建特殊的攻击探测逻辑，也能阻挡这些攻击。
其它项目从Mongrel身上得到的第二个好处，是Luis Lavena所提供的Win32支持。从Mongrel在Win32平台上成功之后，我看到了一些说Luis让其它项目获得了Win32平台兼容性的好消 息。有谣言甚至说Luis和它的朋友们为Win32用户打开了Ruby世界的整个大门。我希望对Daniel Berger的win32utils（http://rubyforge.org/projects/win32utils/）项目也有同样的帮助。
问：在Mongrel背后的一个巨大力量是它速度快、几乎是纯Ruby代码。你作了哪些优化工作？你使用了什么工具？
答：我在优化（也包含校验）C代码时，使用的主要工具是valgrind（http://valgrind.org/）和kcachegrind （http://kcachegrind.sourceforge.net/cgi-bin/show.cgi）。这两个都是非常奇妙的免费工具。但是 Ruby在valgrind下运行得并不好。后来我转而使用kcachegrind。
性能检测工具我使用httperf（http://www.hpl.hp.com/research/linux/httperf/）。当我在做了一个期待着能有性能提升的改动后，但并没有改观时，我就用它重新检测一下，再做一些其它可能有用的努力。
整个过程都用了比较科学的方法。因为我从Ruby得到的有关性能的消息非常少，我只有不断的测试、评估、调整，不断的重复这个过程，直到确认性能指数真的提高了。使用统计学测试真正有用的地方在于，确认每一次的变动的确有了一些不同，或者至少确保没有带来坏处。
我当然也使用Ruby的性能库（profiling library），但我只是在仅有Mongrel运行的地方作非常有限的测试。当Mongrel和其它的应用框架一起运行时，这些框架有可能拖慢了 Mongrel的速度，用Ruby的性能库就得不到任何有用的性能信息。
举一个例子，在一个简单的测试中，我用YAML包来返回HTTP请求，我不能使用Ruby的性能库，因为YAML库是个猪，所有的性能信息都是YAML 的。Mongrel的信息只有一丁点儿。Rails或者Camping的性能测试也同样的情况，它们自身的性能数据多过Mongrel的。
当我对性能非常敏感的时候，我使用R工具(http://www.r-project.org/)来作有计划的性能数据分析。
问：最近，你做了许多工作比如单元测试，好让Mongrel稳定、安全。你能解释一下你的方法论，和你使用的工具？
答：我非常赞同OpenBSD团队所宣称的，安全漏洞来自于一般的缺陷，而不是来自于你在源代码里面找到的那些特定的“安全漏洞”。这意味着我认为我修正了我所能找到的所有安全漏洞，并且积极的对待那些潜在错误之后，我会在这个过程中阻止许多漏洞。
在我的所有项目中，我拼命的做到以下几点：
１、保证代码近可能的简单。
２、在发布我的代码之前，做Code review，持续的发现
a、“丢失的断言”－对于输入输出的不正确的假设
b、“丢失的else”－没有覆盖到所有的逻辑分支
c、“期待它会中止”－死循环或者短命循环错误
d、“检查返回值”
e、“预料之外的异常”
f、“简单、可读”－用可读性强的代码替换奇技淫巧的代码；对复杂的代码写好文档以便其它人可以理解
３、尽可能的做单元测试
４、外部的破坏性测试和性能测试。用不正确的输入让你的系统崩溃，高负荷，停止中间流的干扰，随机的拆开资源。总之想尽一切办法搞烂你的系统。
５、用户可用性评价。我认为如果一个系统是易于使用的，安全性问题就会少一些。但是我现在没有实例来证明我的声明。
最终的结果，Mongrel可以在HTTP协议层阻挡海量的攻击。这也许不能说明Mongrel是固若金荡的，但是Mongrel正在朝这条路上走。
问：Mongrel要达到的下一个目标是什么？
答：最近的一个工作是改进Mongrel的布署文档。日前为止还只有一个配置Lighttpd,在各种平台上群集的文档。一旦这些文档完成了，布置Mongrel会更容易。特别是那些已经使用了其它应用服务器比如Tomcat的人们。
问：你是如何对待那些Mongrel的反馈和建议的？
答：这些反馈都是非常积极的。最关心的问题，也是最值得考虑的问题。
许多人都问到了布署问题，我将用良好的文档来解决。其它人问到了群集的管理，我希望Bradley Taylor（来自RailsMachine.com）将要提交的群集插件能解决这个问题。其它一些人问到了licenses，我会在FAQs中说明。
有一些顽固的问题，是关于如何处理caching和多个复杂动态web站点时的负载均衡。对于这两个问题我目前无能为力，我会想些好点子，我希望我的下一个项目能解决“缓存问题”。
问：Mongrel有什么障碍吗？
答：我得说，Mongrel的最大障碍，是让它成为一个生产性的平台。我每天都从社区中收到许多来信，说一他们认为Mongrel是多么的坚如磐石，但就是没有一点关于使用Mongerl作巨型productiong布署的消息。我觉得在未来的几个月里，情况会好起来的。
问：你最喜欢的５个库或者框架是什么（标准库中的或者社区的都行）？
答：我要说说Camping框架。它有着太多的魔力，让我不得提到它。Mongrel从它身上得到许多代码和思想。
我使用webgen(http://webgen.rubyforge.org/)来管理Mongrel的网站。它可以非常容易的从一组简单的wiki格式的页面中生成静态站点。
网络性能测试工具，我只选httperf。它是唯一的一个能够精确的统计分析，打断整个的request/response链，精确的报告socket错误，每一个分析项都有精确的定义，容易使用的分析工具。
我也非常的喜欢Lua语言（http://www.lua.org/），我把它当成Ruby的一个轻量级的替代者。它非常快，简洁，非常容易的就能embed到其它程序中去。有着和Ruby相似的、并不陌生的语法。
问：Ruby,Rails,Mongrel和Zed，它们各自的下一步计划是什么？
答：关于Ruby的这得去问Matz，Rails的要去问David。我能说的是，我希望Ruby和Rails将会是什么样子。
关于Ruby，我希望看到两个结果。第一个是它能简单的运行在valgrind下。让它稳定、保持简洁还要走很长的路。第二点是集中那些致力提高Ruby效率的人们的分散力量，到Ruby1.9的虚拟机项目上来。
对于Rails，我希望它能少些臃肿(fat)；ActiveRecord能有一个像样的的连接池系统。
对于“臃肿”，我相信DHH已经计划着把一些事情移到类似Active Web Service的plugins中去。对于ActiveRecode，需要作一些重构，让数据库连结池看上去和Hivernate的一样。这对那些使用基 于连接计数license的商用数据库用户来说尤为重要（按数据库连接数付license费）。
Mongrel的未来看起非常光明。我将在发布第一个production版本时，把这个进程再推向前一步。像java一样，我会取个“Mongrel 0.4 Enterprise Edition 1.2”的名字（像Java Enterprise Edition 1.2）。
我的下一个大项目，可能是一个caching proxy服务器，目的是让所有的动态web应用性能更好、更快。
（完）
英文原文出处：
http://www.oreillynet.com/ruby/blog/2006/05/post.html
翻译：
alang (http://my.donews.com/alangs)
Zed Shaw 是一个在Ruby世界中声名鹤起的开发者，它是Mongrel(一个Ruby的web服务器)的作者，因快速、稳定、安全而出名。在这个访谈中，他讨论了Mongrel,Ruby,和他的创建良好代码的经验。
问：你是怎么来到Ruby世界中的？
答：多年前，我在开发一个怪异的控制工具－－我叫它FastCST时－－接触到Ruby时。我试了一下Ruby,但是不得要领，马上就回到了C语言了。当 我读了Curt Hibbs的文章时，才了解到，Hey,他们在用这个东西在做领域语言（domain specific languages ）。从那时起，我就开始开发一个Ruby版本的FastCST，然后我对这件事厌烦了，因为同时还有其它的几个Rails项目。
问：许多人都在说，Ruby和Rails不适合做“企业级应用“ ，你怎么看这个问题？
答：在回答这个问题之前，我必须要明确人们所谓“企业级应用”的定义，可以概括为三点：
１、庞大、昂贵
２、可扩展性，性能，满足我的服务需求
３、法律上有保障的商业技术支持，用以掩盖潜在的失败。
问：Okay,让我们一点一点的来谈，Ruby和Rails都是免费的，它们怎么得到花费昂贵（的人们）的认可？
答：他们的定义，企业级应用意味着你要花费上百万的money在硬件和软件上。这么多年来，他们一直在灌输这个观点，是因为他们要从中得益。实际上你的解决方案要符合你的真实需求。如果你需要一个庞大的解决方案，是因为你并没有真正了解你到底需要什么。
Rails在解决这些问题时，并不需要你花费那么多的资金。
问：那么，Rails的可以扩展性呢？
答：那些企业级应用中的“扩展性”，我都可以用Mongrel来解决。首先，要把可扩展性与高性能要区别开来，同时要回到资源的可以扩充性上来。一旦你把这二者区分开来，你就能得到一个两者旨顾的正确答案。
Rails的扩展性（指的是满足需求的可扩展性），和其它的Web应用框架一样好。Mongerl让这个工作变得非常简单，它非常快，基于HTTP。如果 你以前用过Tomcat,Resin,WebLogic或者Apache+PHP，那么Mongrel运行Rails会达到同样的效果。
其实我是承认Ruby的效率不高的。Ruby的社区曾经有意的忽略了“高性能”这个房间里的大象，他们必须正视这一点。现在已经有了一些成果，让ruby 变得快一些。但是还有许多问题要解决。有一个叫YARV的虚拟机已经展示了一些成果，(对Ruby)的加速已经可以和java的解决方案(jRuby?) 相提并论了。
Ruby的闪光点不在于它的运行速度，而是在于它的开发速度。我可以证明这一点，我在Mongrel上花了三个月的时间，它已经是一个全功能、稳定、高效的web应用服务器，可以用它来支撑许多Ruby站点。如果不用Ruby，这个开发进度是不可想像的。
Rails的问题又不同于Ruby，因为Rails自己有着优秀的缓存机制，这在一定程度上弥补了Ruby的“龟速”。Rails用"page caching"、"fragment caching"来加速应用。如果你善用这个功能，良好的规划你的缓存方案，你可以得到和静态页面一样的网络性能。甚至比Java或者PHP的做得还要 好。
问：那么，商业化的技术服务呢？
答：Rails现在还做得不够好，但是，情况会越来越好。会有越来越的资金投入到这个(Rails)服务领域来的，他们会像PHP类似的众多服务一样做得很好的。如果你看看PHP，最开始只有Zend一家在做这个服务，后来有越来越多的大公司加入到服务的行列中来。
问：在开始做Mongrel之前，你在开发SCGI，说一说它们之间的相似之处，谈谈他们如何协作，或者不协作？
答：SCGI(http://www.zedshaw.com/projects/scgi_rails/) 是我的第一次替代FastCGI(http://www.fastcgi.com/)的尝试。SCGI的目的是高效的支撑纯Ruby应用，目的已经达到 了。但是，SCGI在多web服务器中的支持是有限的。并且不是将来开发的选择。Lighttpd的支持发源于对它的mod_fastcgi的突兀的修 改。Apache的SCGI模块来自于Apache项目之外，并且Apache项目着重声明过对FastCGI的支持要多过对SCGI的支持。事实证明了 许多人在Apache上使用SCGI都遇到了麻烦，特别在与多个后台通信时，SCGI看上去不妙。
Mongrel最开始是作为一个SCGI的代理，来试图解决这个问题。我写了一个Http的解析器，然后用C写了一个代理程序来响应请求，再转发给 SCGI。做到一半的时候，我意识到这个解析器写的是如此的完美，让我决定跳过中间部分，直接写用Ruby写一个web服务器。大约一天之后， Mongrel诞生了。
我的对SCGI的计划是，简化它，只满足最基本的要求。SCGI里面目前有许多的DRb(分布式Ruby)管理代码，还有一些其它人使用(滥用)的片断， 但是，这对那些只是希望使用SCGI来工作的人来说没有一点用处。为了支持那些目前使用SCGI的用户，我将移植一些Mongrel的发明过去，比如 thread模型。要简化SCGI，让它回到最初的面目上去。
说了这么多，我想你已经明白了我未来的工作主要是Mongrel，我认为它是支持Ruby web应用的比较power的方法。
如果有任何人对接手SCGI的工作感兴趣，我欢迎。它在RubyForge上有个项目主页，有兴趣和有能力的人来吧，我已经准备好了交出它的管理权。
问：你在Mongrel上的工作是如何影响你在Rails上的工作的？或者相反？
答：在Mongrel中，我必须用到的Rails代码非常的少，这是为了让Mongrel与Rails保持比较松散的偶合，这样当他们（Rails）在某个release版中改了什么东西并且让程序崩溃时，Mongrel不受影响。
当我在用Rails上开发时，我积极的使用Mongrel，并且记下哪些方面要作改进。这让我可以保证Mongrel的实用价值，而不是为了纯粹的学术目的作的凭空想像。
举个例子，我在windows平台上做开发，那简直是不可思义的痛苦，主要的原因不在于windows本身，而是开发Rails的人（DHH之流），从来 没有深入的使用过windows（原话：从来没有走进过windows电脑五英尺）（译注：DHH等人整天的show他们的Apple笔记本，什么时候想 过windows用户）。Luis Lavena做 的许多改进让事情变得好了些。对于我这样的、还有其它许多贫穷的使用windows的粗人来说（是啊，相对于用Apple电脑的人来说，我也好穷啊。但也 不是粗人吧），我要让Ruby on Rails更容易使用些。 （深得我心啊！在Mac平台上开发Rails无疑是绝佳的体验，但，我买不起MacBook！）
问：我知道你在为Rails和Nitro camps上能运行Mongrel而努力。目前最大的障碍是什么？
答：最好的事情是让Mongrel变成框架无关的。我是唯一的一个能让Rails与Mongrel协作的人。Rails核心开发团队的一些家伙主要是在开 发时测试Mongrel，但是我自己，Luis Lavena，其他的几个人，几乎做了让Mongrel产品化的全部工作。我和Luis是唯一被期待用Rails来做产品的人。（译注：说到这里，Zed 好像有些愤愤不平的情绪在里面）
Nitro，camping，还有IOWA团队的人，为我做了许多（mongrel适应）他们平台上的工作。他们下载Mongrel，阅读文档，初期会打扰我，但是大部分时候不要我插手。
我觉得我帮助Campng项目最多，但实际上管理Mongrel的代码要归功于Camping。它回馈给我的是一个大文件的上传/下载补丁，这个补丁放在了0.3.12.5发行版中。因为他说他是在给ParkPlace做DVD的上传/下载时碰到了。（这下对Mongrel做下载类的网站放心了）
问：Mongrel给那些使用它的项目们回报什么了呢？
答：我认为有两件最大的回报，一是安全性增强，二是win32平台的支持。
Mongrel的设计考虑了大多数HTTP服务器碰到过的安全问题，这些问题来自于过于散漫的HTTP协议手工代码处理。Mongrel使用了一个生成处 理器（使用了Ragel：http://www.cs.queensu.ca/home/thurston/ragel/）,它非常稳固、优秀，可以阻挡 大量的网络攻击。因为这个保护是来自于HTTP协议层的，所以使用Mongrel的任何框架都可以免费的使用它。
在EastMedia/VeriSign项目中，我们遇到了一波来自某“安全公司”的网络攻击。在这里我不想指出这家公司的名字，以免给他们做了免费的广告。他们在没有事先通知我们的情况下，对还没有发布的机器，使用了一些扫描软件。
好在Mongrel在HTTP协议层阻挡了所有的攻击企图，没有费一点事就把他们踢了出去。但是就在同时，Apache却让这次攻击通过了代理服务器，一点报警都没有。
当他们进行了自动扫描之后，我们知道了有一些在安全公司的手写代码攻击的人，被Mongrel所做的深深吸引住了。
最有趣的部分是，Mongrel所做的全部，是使用了一个基于文法和解析生成器(Ragel)的正确的解析器。其它web服务器使用人工编写的HTTP解 析器，被证明是易受攻击的、难于与真正的HTTP1.1 RFC规范相比较，维护起来也是非常痛苦的。使用了Ragel之后让Mongrel非常的稳固，不需要创建特殊的攻击探测逻辑，也能阻挡这些攻击。
其它项目从Mongrel身上得到的第二个好处，是Luis Lavena所提供的Win32支持。从Mongrel在Win32平台上成功之后，我看到了一些说Luis让其它项目获得了Win32平台兼容性的好消 息。有谣言甚至说Luis和它的朋友们为Win32用户打开了Ruby世界的整个大门。我希望对Daniel Berger的win32utils（http://rubyforge.org/projects/win32utils/）项目也有同样的帮助。
问：在Mongrel背后的一个巨大力量是它速度快、几乎是纯Ruby代码。你作了哪些优化工作？你使用了什么工具？
答：我在优化（也包含校验）C代码时，使用的主要工具是valgrind（http://valgrind.org/）和kcachegrind （http://kcachegrind.sourceforge.net/cgi-bin/show.cgi）。这两个都是非常奇妙的免费工具。但是 Ruby在valgrind下运行得并不好。后来我转而使用kcachegrind。
性能检测工具我使用httperf（http://www.hpl.hp.com/research/linux/httperf/）。当我在做了一个期待着能有性能提升的改动后，但并没有改观时，我就用它重新检测一下，再做一些其它可能有用的努力。
整个过程都用了比较科学的方法。因为我从Ruby得到的有关性能的消息非常少，我只有不断的测试、评估、调整，不断的重复这个过程，直到确认性能指数真的提高了。使用统计学测试真正有用的地方在于，确认每一次的变动的确有了一些不同，或者至少确保没有带来坏处。
我当然也使用Ruby的性能库（profiling library），但我只是在仅有Mongrel运行的地方作非常有限的测试。当Mongrel和其它的应用框架一起运行时，这些框架有可能拖慢了 Mongrel的速度，用Ruby的性能库就得不到任何有用的性能信息。
举一个例子，在一个简单的测试中，我用YAML包来返回HTTP请求，我不能使用Ruby的性能库，因为YAML库是个猪，所有的性能信息都是YAML 的。Mongrel的信息只有一丁点儿。Rails或者Camping的性能测试也同样的情况，它们自身的性能数据多过Mongrel的。
当我对性能非常敏感的时候，我使用R工具(http://www.r-project.org/)来作有计划的性能数据分析。
问：最近，你做了许多工作比如单元测试，好让Mongrel稳定、安全。你能解释一下你的方法论，和你使用的工具？
答：我非常赞同OpenBSD团队所宣称的，安全漏洞来自于一般的缺陷，而不是来自于你在源代码里面找到的那些特定的“安全漏洞”。这意味着我认为我修正了我所能找到的所有安全漏洞，并且积极的对待那些潜在错误之后，我会在这个过程中阻止许多漏洞。
在我的所有项目中，我拼命的做到以下几点：
１、保证代码近可能的简单。
２、在发布我的代码之前，做Code review，持续的发现
a、“丢失的断言”－对于输入输出的不正确的假设
b、“丢失的else”－没有覆盖到所有的逻辑分支
c、“期待它会中止”－死循环或者短命循环错误
d、“检查返回值”
e、“预料之外的异常”
f、“简单、可读”－用可读性强的代码替换奇技淫巧的代码；对复杂的代码写好文档以便其它人可以理解
３、尽可能的做单元测试
４、外部的破坏性测试和性能测试。用不正确的输入让你的系统崩溃，高负荷，停止中间流的干扰，随机的拆开资源。总之想尽一切办法搞烂你的系统。
５、用户可用性评价。我认为如果一个系统是易于使用的，安全性问题就会少一些。但是我现在没有实例来证明我的声明。
最终的结果，Mongrel可以在HTTP协议层阻挡海量的攻击。这也许不能说明Mongrel是固若金荡的，但是Mongrel正在朝这条路上走。
问：Mongrel要达到的下一个目标是什么？
答：最近的一个工作是改进Mongrel的布署文档。日前为止还只有一个配置Lighttpd,在各种平台上群集的文档。一旦这些文档完成了，布置Mongrel会更容易。特别是那些已经使用了其它应用服务器比如Tomcat的人们。
问：你是如何对待那些Mongrel的反馈和建议的？
答：这些反馈都是非常积极的。最关心的问题，也是最值得考虑的问题。
许多人都问到了布署问题，我将用良好的文档来解决。其它人问到了群集的管理，我希望Bradley Taylor（来自RailsMachine.com）将要提交的群集插件能解决这个问题。其它一些人问到了licenses，我会在FAQs中说明。
有一些顽固的问题，是关于如何处理caching和多个复杂动态web站点时的负载均衡。对于这两个问题我目前无能为力，我会想些好点子，我希望我的下一个项目能解决“缓存问题”。
问：Mongrel有什么障碍吗？
答：我得说，Mongrel的最大障碍，是让它成为一个生产性的平台。我每天都从社区中收到许多来信，说一他们认为Mongrel是多么的坚如磐石，但就是没有一点关于使用Mongerl作巨型productiong布署的消息。我觉得在未来的几个月里，情况会好起来的。
问：你最喜欢的５个库或者框架是什么（标准库中的或者社区的都行）？
答：我要说说Camping框架。它有着太多的魔力，让我不得提到它。Mongrel从它身上得到许多代码和思想。
我使用webgen(http://webgen.rubyforge.org/)来管理Mongrel的网站。它可以非常容易的从一组简单的wiki格式的页面中生成静态站点。
网络性能测试工具，我只选httperf。它是唯一的一个能够精确的统计分析，打断整个的request/response链，精确的报告socket错误，每一个分析项都有精确的定义，容易使用的分析工具。
我也非常的喜欢Lua语言（http://www.lua.org/），我把它当成Ruby的一个轻量级的替代者。它非常快，简洁，非常容易的就能embed到其它程序中去。有着和Ruby相似的、并不陌生的语法。
问：Ruby,Rails,Mongrel和Zed，它们各自的下一步计划是什么？
答：关于Ruby的这得去问Matz，Rails的要去问David。我能说的是，我希望Ruby和Rails将会是什么样子。
关于Ruby，我希望看到两个结果。第一个是它能简单的运行在valgrind下。让它稳定、保持简洁还要走很长的路。第二点是集中那些致力提高Ruby效率的人们的分散力量，到Ruby1.9的虚拟机项目上来。
对于Rails，我希望它能少些臃肿(fat)；ActiveRecord能有一个像样的的连接池系统。
对于“臃肿”，我相信DHH已经计划着把一些事情移到类似Active Web Service的plugins中去。对于ActiveRecode，需要作一些重构，让数据库连结池看上去和Hivernate的一样。这对那些使用基 于连接计数license的商用数据库用户来说尤为重要（按数据库连接数付license费）。
Mongrel的未来看起非常光明。我将在发布第一个production版本时，把这个进程再推向前一步。像java一样，我会取个“Mongrel 0.4 Enterprise Edition 1.2”的名字（像Java Enterprise Edition 1.2）。
我的下一个大项目，可能是一个caching proxy服务器，目的是让所有的动态web应用性能更好、更快。
（完）