我经常被要求为我们的客户进行规模和容量规划。当我们的客户购买我们的产品（基本上是 J2EE Web 应用程序）时，他们经常会问他们需要什么硬件来运行这些产品。我们的建议通常会导致高成本的硬件采购。
到目前为止，我开发的最佳启发式方法是将利用率预测（应用程序应该参与的注册用户和并发用户的数量）与我们现有安装中收集的数据进行比较。类似于：如果安装 A 使用 X 硬件参加 100 个并发用户，那么安装 B 将需要 2*X 硬件来参加 200 个并发用户。
然而，这种方法存在许多问题。客户经常使用不同的硬件和软件平台。他们从我们这里购买的产品集通常不会相同，并且通常部分应用程序是根据特定客户的订单构建的。考虑到软件版本正在发生变化等，并且有很多参数可以使调整大小的任务变得非常困难。
我研究了一些关于该主题的书籍，有些建议使用复杂的数学模型。这些方法需要作为输入的参数数量（例如应用程序功能的详细分类）使我认为这些几乎没有用。硬件通常在定义基本要求之前就已订购，更不用说这些在应用程序开发和生命周期中会有所不同。那么，您如何进行规模和容量规划呢？任何提示和操作方法表示赞赏。
在您提供的描述中没有简单或数学公式来预测规模，如果您（或您的公司）对此很认真，那么最好的方法是构建一个性能和可扩展性测试环境，您可以在其中轻松设置和拆除各种客户端配置并向他们发送负载以查看他们将如何做。因为您正在构建自定义组件，一个写得不好的组件或缺少索引可能会搞砸一切，因此拥有这样的环境是您可以在提供给客户之前解决这些问题的地方。拥有这种类型的环境后，您可以将内存和 cpu 添加到应用服务器和数据库，以查看您的应用程序如何扩展。
我会建议一个虚拟机环境，他们可以根据应用程序的需要轻松添加 CPU 和内存，并使用 watchmouse 或 browsermob 等服务进行一些实际的外部负载/规模测试。
如果必须在定义基本需求之前订购硬件，那么您能做的最好的事情就是通过查看类似项目的安装基础来确定容量（就像您现在所做的那样）。跟踪现有客户在扩展安装方面的经验和容量需求，如果您有足够大的基础，您可能可以通过将具有相似硬件的类似项目分组并查看容量需求来进行粗略的曲线拟合。观察现有客户容量需求在增长过程中的变化以及其他数据点。
理想情况下，最初的硬件/软件购买是用于试点安装，一旦启动并符合规范，您就可以对试点设置进行基准测试。使用这些结果来预测从试点到生产的能力需求。当然，这需要在试生产计划中对应用程序进行基准测试，然后订购和接收设备。但它会比预先做所有事情提供更准确的容量估计。
如果应用程序以优雅的方式水平扩展，粗略的初始估计可以作为起点。一旦应用程序在生产中运行，根据需要添加或删除额外的框应该很容易。