您应该做的一件事是对现有的单服务器应用程序进行负载测试，以查看它一次可以支持多少会话和用户。一旦知道这一点，您就可以随着时间的推移监控这些相同的指标。当您的数量开始接近已知限制时，就该开始准备新硬件以进行部署了。您将需要考虑额外服务器的交付时间，以便您可以在现有系统达到其限制之前进行部署。这是一个非常笼统的概述，细节在 John Allspaw 的“容量规划的艺术”一书中有很好的介绍。
话虽如此，我还是将数据库服务器和Web服务器分解为各自的系统作为起点，然后分别进行负载测试以确定理论负载。通常 Web 服务器首先会成为瓶颈，因此您的应用程序在编写时应该考虑到可伸缩性。问题提到了会话，根据您使用的平台，有几种方法可以在服务器之间共享会话，将它们存储在中央数据库中，或者使用负载平衡硬件将同一用户定向到同一服务器，除非它变得不可用由于某些原因。
想一想：从一开始。
开始添加：当您遇到第一个“服务器太忙”错误时。任何更早的事情都是过早的优化。
（除非您的 Web 应用程序是关键任务，在这种情况下，您可能不是从头开始，也不需要轮询 serverfault.com 社区。）
但说真的，对于现代消费者 Web 应用程序，让“服务器太忙”实际上可能是一件好事。它肯定不会伤害 Facebook、Twitter 或 YouTube。过早添加服务器的危险在于，您的应用程序永远不会像您预期的那样受欢迎，并且您最终会浪费本可以用于功能开发的资金。
如果您是真正拥有热门网络资产的少数幸运者之一，那么 (a) 恭喜您，并且 (b) 您将能够从日志文件中衡量平均响应时间，并且可以采取更多的指标驱动添加服务器的方法。
就我个人而言，我总是从一个独立于数据库服务器的 Web 服务器开始。
（基于 IIS6 和 SQL Server）
但是，我们在 vmware 服务器（实际上是 3 节点集群）上完成所有这些工作，而 webserver 和 db 服务器只有 1 个 vCPU 和 1GB RAM。他们支持相当繁忙的网站套件（外部和内部网）而无需太多汗水。
但我知道，如果我的人气激增（这可能有一天会发生！）我可以快速重新配置虚拟机，使其具有更多 RAM 和 CPU。
实用说明：随着时间的推移监控您的表现。跟踪变化并积极主动。
当您设计应用程序时。我见过太多的应用程序不是为使用多台服务器而设计的，而逆向工程以后可能会很可怕。
确保您也在多台服务器上进行测试。再次。我已经看到许多应用程序在开发/测试中运行良好，但在生产中却失败了，因为它们无法处理负载均衡器、防火墙、未考虑多播等等等。
添加另一台服务器的时间是当您的容量管理统计数据表明您将在添加另一台服务器所需的时间内耗尽容量时。
您正在收集容量统计信息吗？不？然后是与您的应用程序开发人员和基础设施管理人员讨论的另一件事。
我不同意等到你真的“服务器太忙”并激怒你的用户是正确的做法。将新服务器添加到生产环境可能是一个漫长的过程，并且等到出现错误后再开始是不明智的。
正如其他人所提到的，这个问题很模糊，但实际上有一个非常简单的答案：
当当前服务器的限制开始让您花钱时，您需要添加另一台服务器。
如果您提供免费服务，那么就没有动力添加额外的服务器。
如果您从服务中赚钱，那么您可以进行成本/收益分析：额外的服务器将如何提高性能，以及会产生多少利润？
您应该做的一件事是对现有的单服务器应用程序进行负载测试，以查看它一次可以支持多少会话和用户。一旦知道这一点，您就可以随着时间的推移监控这些相同的指标。当您的数量开始接近已知限制时，就该开始准备新硬件以进行部署了。您将需要考虑额外服务器的交付时间，以便您可以在现有系统达到其限制之前进行部署。这是一个非常笼统的概述，细节在 John Allspaw 的“容量规划的艺术”一书中有很好的介绍。
话虽如此，我还是将数据库服务器和Web服务器分解为各自的系统作为起点，然后分别进行负载测试以确定理论负载。通常 Web 服务器首先会成为瓶颈，因此您的应用程序在编写时应该考虑到可伸缩性。问题提到了会话，根据您使用的平台，有几种方法可以在服务器之间共享会话，将它们存储在中央数据库中，或者使用负载平衡硬件将同一用户定向到同一服务器，除非它变得不可用由于某些原因。
但是要回答核心问题“我们什么时候知道什么时候做”，这将是关于您收集的指标并将它们与通过负载测试得出的已知限制进行比较。
如果没有关于您的应用程序的任何进一步信息，很难给出任何具体建议，但这里有一些幻灯片来自 Brad Fitzpatrick 2005 年关于 LiveJournal 基础架构的演示文稿（重点强调数据库负载平衡）：
http://www.scribd.com/doc/2684169/LiveJournal-scaling
一般来说，从一个前端到多个前端比将前端与（通常是数据库）后端分开更棘手。但是，仔细使用负载平衡器和“粘性”会话可以使这种过渡更容易。
至于“何时”，找到它的关键是衡量您的网络（和数据库）服务器的性能。理想情况下，在具有实际流量负载的测试台上，然后查看性能下降到“不够好”的位置。一旦实时站点上的负载开始接近“不够好”，您就订购了一个新的前端。
如果您大致了解何时需要新服务器以及流量如何随着时间的推移而增长，您可以瞄准在需要之前部署新服务器。不幸的是，我不能给你任何确切的数字，因为这些东西在很大程度上取决于你的设置细节。