更新：更精确的措辞可能是“开发CRUD Web应用程序时典型的性能瓶颈是什么？”
我正在考虑以下网络应用程序：
我正在考虑使用以下编程语言：
我在想数据库系统，如：
我正在考虑以下操作系统：
我正在考虑典型的现成硬件配置：
http://english.keyweb.de/dedicated/index.shtml
我想到的可能的软件瓶颈是：
我想到的可能的硬件瓶颈是：
答案 0 :(得分：10)
如果您构建Web应用程序以获得最大的可伸缩性，那么您的瓶颈最终将归结为协调可变状态的管理（即数据库中需要某种形式的事务语义的部分）
需要考虑的一些要点：
不需要同步/交易的静态或数据可以在许多小型商用服务器上廉价地复制。您的NoSQL解决方案（CouchDB等）应该很好地处理这个问题，并结合静态Web数据的许多优秀缓存解决方案。
通过添加更多Web服务器节点，可以轻松地水平扩展本地CPU处理能力（例如，处理单个Web请求）。考虑到现代处理器速度，CPU速度不太可能成为您的瓶颈 - 大多数Web应用程序并不需要太多的CPU能力。
然而，事务性数据更新是一个非常棘手的问题。如果您想了解理论解释，请阅读拜占庭将军问题，但基本上不可能在分布式系统中可靠地协调交易。您必须根据您最重视的内容（数据完整性？性能？可伸缩性？容错性？成本？延迟？）做出一些妥协。
操作系统等并没有太大的区别 - 开销很低，并不会真正影响可扩展性问题。选择你掌握的技能和/或你认为你会发现最容易管理的技能。我个人使用Ubuntu on Amazon EC2。
鉴于您正在考虑的应用程序类型，我可能会对NoSQL解决方案犯错，因为它听起来有效处理大量数据比拥有大量事务数据更重要。您可以随时为需要事务语义的有限数据子集保留PostgreSQL框（用户帐户？主参考数据？某些工作流状态？）
另一种（更经典的）方法是获得典型的大型数据库（例如Oracle，DB2）并购买昂贵的高端数据库机群。然后有许多廉价的，复制的Web服务器完成大部分工作，并在需要执行事务时根据需要访问数据库集群。这可以非常好地工作到数据库集群开始过载的程度，此时它可能是一个昂贵的瓶颈来扩大......但可以说，如果你负担得起那么多的负载。如果你正在修建，我会沿着这条路走下去金融服务应用程序。
如果你只是做一个原型或期望开始时的小负载，那么你可以使用一个商品PostgreSQL机器来代替昂贵的数据库集群。这可能是设置最简单/最便宜的选项。如果您将数据库访问权限保持在最低限度（大量缓存，仔细查询设计），它实际上可能需要很长时间。请注意，如果你继续成长，它最终会成为你的瓶颈。
P.S。你提到你正在看Clojure，如果你还没有这样做，那么我强烈建议你观看这个视频：http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey - 一个非常独特的并发视角，它也提供了一些关于并发管理事务数据的问题的见解。的环境中。
答案 1 :(得分：4)
取决于（tm）。如果您的应用程序有足够的流量来帮助您进行护理，请计算自己的幸运。
答案 2 :(得分：1)
就个人而言，范围蔓延。保持简单，并以较少的功能运送它。
列出的“可能的瓶颈”都不是简单应用的问题。如果您开发了一个复杂的功能集，您可能会遇到处理器/内存限制，具体取决于您选择的服务器。找出答案的最佳方法是构建您的应用程序，看看会发生什么。如果硬件的特定组合不足以满足您的应用程序的需求，请感谢有一百万个选项需要切换到。
具体来说，如果您要抛出一个Rails应用程序，请从Heroku开始，一旦维护成本过高，就转移到EC2实例。你的遗嘱不会有任何困难，而且有更多的时间专注于重要的事情，比如制作你的应用程序。
答案 3 :(得分：0)
在大多数典型情况下，除了你做的完全错误之外，你不会有任何瓶颈而不是开发人员的生产力。
当您遇到其他瓶颈时，您可能会有足够的用户和资金来消除它们。