ruby-on-rails - 开发 CRUD Web 应用程序时的典型瓶颈是什么？

Question

更新:更准确的措辞可能是“开发 CRUD Web 应用程序时典型的性能瓶颈是什么？

我正在考虑 Web 应用程序，例如:

博客 CMS

词汇培训师

网址缩短器

网络论坛

我正在考虑编程语言，例如:

ruby

斯卡拉

Clojure

我正在考虑数据库系统，例如:

PostgreSQL

MongoDB

沙发数据库

我正在考虑这样的操作系统:

Mac OS X

Linux

我正在考虑典型的现成硬件配置:

http://english.keyweb.de/dedicated/index.shtml

我想到的可能的软件瓶颈是:

编程语言

数据库系统

操作系统

我想到的可能的硬件瓶颈是:

中央处理器

内存

硬盘

网络

Answer 1

如果您构建 Web 应用程序以获得最大的可扩展性，那么您的瓶颈最终将归结为 协调可变状态的管理 (即需要某种形式的事务语义的数据库部分)

需要考虑的几点:

不需要同步/事务的静态或数据可以是 廉价复制跨越许多小型商品服务器。您的 NoSQL 解决方案(CouchDB 等)应该可以很好地处理这个问题，并结合任何用于静态 Web 数据的出色缓存解决方案。

通过添加更多 Web 服务器节点，本地 CPU 处理能力(例如处理单个 Web 请求)很容易水平扩展。考虑到现代处理器的速度，CPU 速度不太可能成为您的瓶颈——大多数 Web 应用程序实际上并不需要太多的 CPU 能力。

然而数据的事务更新是一个非常棘手的问题。阅读 拜占庭将军的问题如果你想知道理论上的解释，但基本上不可能在分布式系统中可靠地协调事务。您必须根据您最看重的东西(数据完整性？性能？可扩展性？容错性？成本？延迟？)做出一些妥协。

操作系统等并没有太大的区别 - 开销是如此之低，并且它并没有真正影响可伸缩性问题。选择你拥有的技能和/或你认为你会发现最容易管理的东西。我个人使用Ubuntu on Amazon EC2 .

鉴于您正在查看的应用程序类型，我可能会偏向 NoSQL 解决方案，因为听起来有效地处理大量数据比拥有大量事务数据更重要。您始终可以为需要事务语义的有限数据子集保留一个 PostgreSQL 框(用户帐户？主引用数据？一些工作流状态？)

另一种(更经典的)方法是获取典型的大型数据库(例如 Oracle、DB2)并购买昂贵的高端数据库机器集群。然后让大量廉价的、可复制的 Web 服务器完成大部分工作，并在需要执行事务时根据需要访问数据库集群。这可以非常好地工作到数据库集群开始过载的地步，此时它可能是一个昂贵的瓶颈扩大......但可以说，如果你得到那么多负载，你可以负担得起.如果你正在 build 例如，我会沿着这条路线走。金融服务应用程序。

如果您只是在做一个原型(prototype)或期望从小负载开始，那么您可以使用单个商品 PostgreSQL 机器来代替昂贵的数据库集群。这可能是最简单/最便宜的设置选项。而且，如果您将数据库访问保持在最低限度(大量缓存、仔细的查询设计)，它实际上可以带您走很长一段路。请注意，如果您继续成长，它最终将成为您的瓶颈。

p.s.您提到您正在查看 Clojure，如果您还没有这样做，那么我强烈建议您观看此视频:http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey - 一个非常独特的关于并发的观点，它也对在并发环境中管理事务数据的问题提供了一些见解。