位图/ openGLimage processing服务器的硬件build议？

稍后我pipe理了一个类似的服务器集群（两个成员集群），我的基本方法是CPU bottleneck... max out processor speed and core count 。 这也是在高端服务器，有大量RAM，高容量固态硬盘（用于快速访问临时存储在其上的图像）和多个1Gbit网卡，再次以最大化性能，从而处理图像的吞吐量。

工作得很好，而且对于什么是关键业务function来说，工作量很大，MBA和其他西装很乐意投入额外的25000美元硬件来使事情顺利进行。 一旦我把我推荐给他们的好处，至less。 是的，我认为你至less有点过度思考这个问题。 从“只是”抛出强大的硬件问题开始。 如果这不能提供所需的性能，那么您需要担心优化代码和检查stream程瓶颈。

在我进入创build和“推销”我的build议的基本过程之前，让我指出一个SA格言：

It's better to over-engineer than under-engineer.

• （在这个特定的例子中，比起“太less”的一方来说，服务器的“太多”太多了。）

我想说，你的情况听起来很相似，我会build议一个类似的方法。 而且我想下面的任何一个都不是严格意义上的“系统pipe理”，所以你可能在这里停止阅读，但是它们都是非常密切相关的，如果你不能有效地向业务部门推销你的build议，那么系统pipe理和架构就是地狱…如果可以的话，你可以称自己为系统工程师/架构师，并且要求更多的钱用于本质上相同的工作，因为你有能力将你的想法简单地用于“慢儿”。 （高pipe和MBA）

我的过程：

1. 做基本的基准，并使用简单的预测，以获得一个基本的球场需要什么样的performance。
   • 创build一个估计，并帮助我select硬件（一般意义上），我会拿出3个规格。
     • 至less我认为会起作用（如果我的数字有点偏差，这实际上是最低+ 15％给我一个缓冲区/安全边际）
     • 合理的最大/“最佳”可能的configuration
     • 一个中等价值，这是两者之间的东西。
   • 基于业务优先级（节省资金？在这个系统上的最大输出/性能？有些妥协？），我会做一个我的build议，其他两个包括应该工作的选项，如果我的build议不被接受。
2. 我将分解每个解决scheme的成本，并尽可能地进行基本的定量成本/收益分析。 在这种情况下，从我的过去来看，这是一个创收的业务stream程，所以这是一个简单的问题， we made $[x] from this last year, on [y] images processed, for a profit of $[z]/image processed, or $[i]/day. 然后，我将硬件的成本转换为相似的单位 – $[x] total CapEx, or $[z]/image processed or $[i]/day 。 （当不同的未来“预测”存在时，对于“预测的”未来数字也是这样做的。）
3. 一旦你完成了这个成本，它就开始计算或者分享它的好处了。 使用这些美元数字和成本比较来通知您的决定（并倡导您的最终build议）是非常有用的，根据我的经验，通常有理由花费额外的可能未充分利用的硬件。
   • 在我所指的情况下，我最初的build议是buy a single mid-range server and slap our image processing stuff on that $70 a day大约$70 a day ， <10 cents an image processed …我们在处理的每张图片上都10 cents了10 cents 。
4. 而且为了让双倍的确定，这些诉讼让我过度devise了冗余的集群build议（这对我来说更容易支持和pipe理）我爆发了服务器上没有足够计算资源的成本 – 潜在的收入损失的容量，每小时在工作站上“手动”（ several hundred dollars an hour ）的费用，并增加了定性好处（ supportability ， ease of management等）和成本（ reputation damage ， angry clients等）顶上的樱桃。 然后再次指出，我推荐的解决scheme$70 a day只需要$70 a day 。

无论如何，这是一个更长，更less的技术比我预期…但我希望你觉得有帮助。