如何计算web应用程序的服务器需求？

Question

我正在开发一个后端，在其中我将公开我的移动应用程序的API。用户可以通过电子邮件/sms/anywhere注册、添加产品、共享产品链接，其他用户也可以点击该链接并购买该产品。这是移动应用程序的简单工作流。该应用程序是一个图像密集型应用程序，它将有图像上传和检索，这将由第三方云服务。所以图像部分不是由后端处理的。

现在我来自开发团队，很少有硬件服务器方面的经验。当我提出对基础设施的要求时，他们问了我以下问题。

1. 应用/存储吞吐量
2. 应用程序吞吐量(编号：在3个月、6个月和1年内的并发连接)
3. 存储吞吐量(3个月、6个月和1年内的数据增长)
4. HA要求
5. DR要求

我不知道如何预测上述3点。如何通过投资计算？据估计，我将在第一个月在我的应用程序上注册10000名用户，其中5,000名将是活跃用户。在应用程序的平均登录中，每个用户将有10个API点击，这将导致5000*10 =每月50,000次点击，这将是每分钟1次API命中，即第一个月有2个并发连接。

计算是这样的吗？如何计算数据的增长呢？这是否意味着，用户注册、创建产品，如果我将所消耗的数据库大小加在一起，这就是所谓的数据增长吗？

这个问题看起来很可悲，但我确实需要帮助，弄清楚吞吐量是如何为服务器需求计算的。

Answer 1

前三点是容量规划。该组织正在努力对未来进行预算和预测。唉，没有简单或可接受的方法来预测性能和可伸缩性。每个应用程序和环境都是不同的。因此，回答这个问题的最好方法是测量。

具体地说：

1. 与管理层或产品所有者讨论用户的可能增长以及不同用户的类型。如果他们不知道，猜测，但文件，这些是猜测。
2. 创建应用程序公共路径的自动运行。您可以记录活动或在负载测试应用程序(如JMeter )中输入自己的活动。
3. 创建一个与当前或预计硬件相匹配的测试环境。密切关注带宽、存储、SSL、日志记录或其他可能影响性能的经常被遗忘的方面。如果可以的话，可以模拟第三方图像服务，使用较小的或有代表性的图像。
4. 使用负载测试应用程序为不同时间的预计用户数创建建议。
5. 使用应用程序性能管理工具(如AppDynamics或DynaTrace )来度量性能和识别瓶颈。

除了上述要求外，这还可以帮助您：

1. 确认您的环境支持所请求的负载。
2. 查找环境支持的最大负载。
3. 找到限制性能或可伸缩性的瓶颈(S)。
4. 用不同的配置进行实验，看看它的表现或规模。
5. 观察系统在触发故障时的处理方式。

最后两点，HA需求(高可用性)和DR (灾难恢复，想必是恢复点目标和恢复时间目标)很难预测，因为它们实际上是业务需求。与管理层或产品所有者讨论可能出现的故障，以及减少或修复这些故障的成本。如果你们两个都是新手，那就期待你们的猜测和深夜吧。

Answer 2

我会提出一个更客观的依据。转到现有的HTTP日志。假设这是对已在外地应用程序的更新，只需提取日志并检查包含的HTTP请求。这提供了一个绝对客观的基础之前，你的负荷建模，而不是一个潮湿的手指在空气中测试风。

同时，从QA的角度记住。您不能同时拥有需求和验证。因此，您可以使用日志中的客观数据来帮助构建负载模型，但是业务人员需要签署实际的定义。为什么？因为您在流中注入了一个到目前为止还没有提供给开发人员、架构师、平台管理人员等的需求。如果你的应用程序失败了，你希望你的业务在你身后，数字是准确的。

你能拉些什么日志？

• 每小时最高交易速率(按小时计算被阻塞的请求)
• 每小时最高用户(计算按小时阻塞的IP地址)
• 用户数据流(请参阅建立以前请求树的referer标记)
• 现有响应时间(如果您为web服务调用启用了w3c时间占用字段)。这可以用于在客观的基础上设定对未来发布的预期，以达到或超过当前的模型。
• 从IP请求之间的延迟中考虑时间。您可以通过抓取referer标记并通过IP地址阻塞来构建一个示例集，从而对任意两个请求之间的时间进行实际建模。然后你可以在这些样本上拉出最小，最大，平均，90百分位数的数据。见鬼，一些统计软件包甚至会为您提供一个函数，您可以在其中插入一个随机数，以获得适合生产的发行版。
• 如果您有前一个时间段的日志，您可以为观察到的和所需的(销售或使用预测)预测增长模型。

我更喜欢这种类型的工作。对于大多数组织来说，你应该可以将价值30天的日志放入免费层，而不必担心在一起安装6个不同的应用程序，就像你使用麋鹿堆栈一样。

如果需求出错，那么您很可能正在追逐生产中永远不会出现的工程幽灵，而且实际上也不会降低任何风险。确保业务方面的人在您的需求上签字，或者您很可能会因为追求非缺陷而拥有单独的预算超支。

Answer 3

我很喜欢你的问题。这是个好主意。我认为没有一个真正的答案，但我会尝试。在创建/设计新服务器时，最重要的是选择正确的服务器

环境和方法。并不是所有的环境都是规模化的，大多数都是有限的。硬件团队试图计算的是，他们可以使用何种类型的文件系统和接口。有些文件系统易于安装，但很难扩展。另一些则很难设置，但易于管理和扩展。

在我看来，最好的办法是联系那些问你这些问题的人，并解释为什么你现在不能回答这些问题。当启动一个新的应用程序或系统时，没有人能说出这一切是如何发展的，特别是在没有其他系统可与之相比的情况下。但是你知道你设计的API，而“硬件人”知道他的环境/Servers是如何工作的。如果你能一起解决这些问题的话，你就能确定。

希望这能帮到你。