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