深入 Python 3

《深入 Python 3》 的内容涵盖了 Python 3 及其与 Python 2 的区别。相对《深入 Python》 ...

↑我也要推荐

沈崴:CherryPy 3 何去何从?

发布时间:2011-06-22 04:01:20, 关注:+7023, 赞美:+9, 不爽:+8

本文标签: web.py

原始出处: 蜻蜓点水 举重若轻

CherryPy 3.0 降临

这次我被等急了。原因是我正在尝试研发一种更为奇怪的 Web Framework。在最后一个稳定版本中, 我使用了 CherryPy2 作为核心组件之一。

毫无疑问, 我是个铤而走险的人。为了让战友们尽早通过轻量级开发获得更多的业余生活, 和快乐的编程体验, 我决定用这一股脑的新体系搞定几个样板工程。所以, CherryPy2 被正式用在了项目中。

我和 CherryPy2 真正意义地交锋了。在第一个项目中, 我遇到了 CherryPy2 稳定性的困扰。事实上我并不觉得这是 CherryPy 独有的问题。我判断问题出在文件上传功能上。

很显然, 应用服务器的一个线程非常宝贵, 它包含了连接池、内存池以及各种功能模块的接口, 通常, 这些基础设施在服务器启动时就已经存在了 (请回忆一下 Plone 的启动时间)。因此, 使用应用服务器来处理文件上传是不合适的。合理的方法是使用 PHP 这类单进程工具, 最好是有一个单独的文件应用服务器来干这个。

但是 CherryPy2 基本上还是能够胜任。而接下来的项目, 拥有相当夸张的访问量需求。因此我做了一次倍受挫折的 benchmark。简单的 CGI 请求, CherryPy2 每秒处理的访问量仅 160 次(当然在真实情景下, 我们的竞争对手远远落后于我们, 不过他们设置了夸张的等待队列, 表示并没有抛弃客户), 而不是号称的 500 次。为此, 我查阅了一下最新资料, 才发现 CherryPy2 要远比 CherryPy1 慢, 通常 CherryPy2 的每秒处理速度在 200 - 300 左右。哦, 我被无意中欺骗了。

事实上, 这已经足够。因为在 RIA 架构 (不要和我扯淡 AJAX) 中, 占大头的是 Apache 静态文件访问。而且瓶颈往往是在数据库服务器上。不过为了保险, 我还是使用了 Psyco 来加速 CherryPy 2。同时 CherryPy2 有一个奇怪的 "API 加速" 开关, 当然我最后打开了这个开关, 这样 CherryPy2 的速度上升到 200 以上 (220 还是 240? 具体数值我已经忘了。Psyco 果然出手不凡。顺便这里提一下, 未优化的 Zope2 在我的 PC 上是每秒 86 个请求)。

当然性能阴影依然笼罩, 所以我只有启动多个 CherryPy2 服务器。每台服务器都维护着一个夸张的数据库缓存。

CherryPy2 给人的印象是已经够用了, 当然如果你觉得不够用, 你的访问量可能已经让你发了财。加服务器吧。但是, 它远没有达到足够好的程度。对初学者来说, 他的性能不够; 对框架设计者来说, 它可能支持了太多特性 —— 或者说支持的特性还不够 (支持过多特性和特性不够, 对框架设计者来说, 就是一码事, 尽管听上去很奇怪)。

最后, 随着我对于 Web 框架设计思想的继续发展, 越来越多计划中的特性和 CherryPy2 发生了冲突。事实上, 我可以直截了当地说, 是因为 CherryPy 过于面向对象了。我已经不止一次地和愚蠢的 OO 思潮发生战争, 最近的一次发生在搜索引擎领域。当然最好不要想当然地以为除了 "面向对象" 就是 "面向过程"。我的意思是除了 1 + 2 + 3 + ... + 100 之外还有其他 N 种更有灵性的方法, 比如 11 x 50。

现在我已经走到十字路口。等待 CherryPy3 或者寻找替代品。

CherryPy3 在 2006 年 9 月份突然出现在我们的视野中。他带来了太多的好消息, 不过和 CherryPy2 不同的是, 它从 Beta2 到 RC1 之间, 是整整两个月。而且我在邮件列表中没有得到任何关于 CherryPy 3.0 RC1 的消息。我相信在国内, 没有人比我更关心这件事情了。即使是 TurboGears, 在国内的玩家都太少了。哦, 这和 Django 有关, 在我看来 Django 是一种非常好的框架, 但是当所有人开始一股脑地追捧它时, 这件事情就开始变得危险起来。或者, 这仅仅是一个多神论者无关痛痒的顾虑。

2006 年 11 月 28 日, CherryPy 3.0 RC1 突然出现在这个世界上。

抉择时刻

下面辩论开始, 是不是到了升级到 CherryPy 3.0 的时候? 这个问题之所以成为问题, 那是因为现在我支持 CherryPy3 的理由和反对它的理由同样地多, 并且他们无一例外, 都是触及灵魂, 而且非常致命的。

我当然应该升级到 CherryPy3。因为至少到现在, 它还没有真正的竞争对手, 或者替代产品出现。

·首先, CherryPy 功能内敛。特别地, 它不自带模板。在今天, 已经是 MVC 扯淡史结束的时代 (毫无疑问, MVC 是重量级架构, 和他吹捧的相反), 服务器端模板再也不是事实上可用的方案 (客户端模板的火焰正在燎原) —— 起码, 我们不能太依赖服务器端模板。服务器端模板, 意味着大教堂、复杂度, 以及客户端逻辑与服务器端逻辑纠缠不休、调试困难和事实上的无法复用。这让我不无遗憾地想到 web.py, 它还是做了太多的事情。

·其次, CherryPy3 在性能上是 CherryPy2 的三倍。这可是个很重的法码。

·CherryPy 对 WSGI 的支持, 也是可圈可点。事实上, 我其实对 WSGI 并没有什么好感。在近五年的时间内, 我一直在研究这种中间件模型, 并且我得出它将最终崩溃的结论。但是它作为标准本身, 是无法抗拒的。

但是 CherryPy 也有许多让我根本无法忍受的问题。

·首先, CherryPy 过于面向对象了。而且, 它强制用户工作在愚蠢的面向对象之下。记得有一次魏中华宽慰我说其实 CherryPy 的 OO 只不过是一种打包模式, 它还没那么面向对象, 我说那好, CherryPy 的最大缺点是面向哈希表编程。不管是面向什么, 这都是 CherryPy 最大的败笔 (当然我必须说这也是他最大的优点, 因为事情变简单了)。

·其次, 翻开 CherryPy3 的 What's New, 我看到了一堆关于配置的改进。优雅的 CherryPy 正在不可避免地向复杂性滑去, 尽管速度没那么快。CherryPy 本身的特性是不能和 Django 相提并论的, 但如果事实证明它在复杂度上却已经接近 Django, 那么将必死无疑。而使用微软愚蠢的 INI 配置格式则又是一大败笔。在我的框架中, 我根本没有考虑, 就做了从 INI 到 ZConfig 的映射。为什么 CherryPy 开发组没有直接使用 ZConfig? 我想这也不能怪他们。使用 ZConfig 的顾虑也好处也可以等量齐观。这件事情要怪只能怪 Guido 没有把 ZConfig 加入 Python 标准库。

随着更多关于 Web 框架的想法将投入实践, CherryPy 的局限性正变得越来越刺眼。但是抛弃 CherryPy 也是不可能的, 因为根本没有替代者。接下来唯一的办法是基于 WSGI 建立我自己的 Web 底层。但是这违反了我的设计哲学: "不重复造轮子, 写最少最有灵性的代码"。也许我会最终想出与 CherryPy 和平共处的办法, 又或许自己动手来开发一个符合我要求的, 简化的替代者 —— 已经无法避免。

好了, 下面我想到我和 Linus 都喜欢讲的一句话: "遇到问题, 是方法错了, 方法对了, 就不再有问题"。

# 老文越读越有味道。后传:如前文所述,沈崴最后开发了自己的高效能服务器:Eurasia

如果你觉得本站对你有帮助,欢迎向本站赞助 :P

使用支付宝捐赠

Copyright© Python4cn(news, jobs) simple-is-better.com, 技术驱动:powered by web.py 空间主机:Webfaction

版权申明:文章转载已注明出处,如有疑问请来信咨询。本站为 python 语言推广公益网站,与 python 官方没有任何关系。

联系/投搞/留言: en.simple.is.better@gmail.com 向本站捐赠