2

目前我们正在实时调整图像大小。我们的用户每天上传大约 50K 到 100K 的图像。我们的服务器 24/7 使用 100% 的 CPU。页面加载时间很慢。拉姆不是问题。

我们有一个双 CPU 英特尔至强 L5630 2.13GHz服务器，具有24 GB内存。我们正在使用一个简单的图像调整脚本从原始图像制作缩略图。但这是最大化CPU的。

我想通过硬件和软件来解决这个问题。

  • 在硬件方面，我们将订购另一台配备双 Xeon 3GHz 处理器的服务器。该服务器将与网站分开处理图像处理。

  • 关于软件，我想请教有经验的人，他们使用什么样的软件来处理具有低 cpu 开销的图像。

任何想法将不胜感激。

4

3 回答 3

1

首先，分析你的读/写平衡和（更重要的）读分布

大多数大容量用户发现最好将上传直接发送到 blob 存储，未经修改，并根据请求动态调整大小。这种方法有很多好处（敏捷性、移动支持、控制），但主要是它可以降低资源利用率。大多数内容永远不会吸引眼球；为什么要在上面浪费资源？

二、获取服务器安全、服务器优化的镜像库

看来您已经在查看我的软件ImageResizer了，据我所知，这是 .NET 唯一对服务器友好的选择。它还提供了一系列管道，每个管道都有自己的权衡。如果您想要原始速度，请使用 WIC 管道；我希望您会看到比当前脚本好 10-20 倍的性能。WIC 流水线的质量不如默认流水线，但速度要快 2-4 倍，而且您无法区分大多数图像。

考虑寻求帮助

我帮助许多公司突破了 100 万和 1000 万的图像障碍；有一些架构缺陷需要避免，但在这种规模下，最好深入了解您的需求。Varnish 或 CDN 是一种选择吗？这些可以极大地帮助扩展超过 500 图像/秒的障碍。

于 2013-02-12T14:19:31.477 回答
0

首先，它们是否需要实时处理？– 如果没有，您可以查看一个基于队列的系统，该系统使用其他服务器/当前服务器上的安静时间来处理缩略图。

图像是否只调整了一次，或者用户是否可以再次请求图像导致另一次调整大小？– 如果是这样，您需要查看缓存。

正在重新处理的图像有多大，一次正在处理多少图像——如果它在一整天内展开？

回发期间调整图像大小是否会导致页面加载时间延迟？– 如果是这样，他们将该指令添加到新线程将改善响应时间。

于 2013-01-11T17:06:11.083 回答
0

首先，您最好将图像处理与主服务器分开。

最佳答案取决于您的特定情况的更多详细信息：什么软件环境，用于调整图像大小的软件，如何配置等。在那里进行优化可能会产生强大的速度提升。例如，是否有多个内核，是否可以使用基于 GPU 的处理？

也就是说，由于每个图像大小调整操作都独立于其他操作，因此有一个通用的解决方案。您可以轻松地将工作分发到任意数量的服务器上。构建一个（或更多，如果需要）额外的图像处理服务器。然后使调整大小请求被分发。这可以在多个级别上完成（Web 客户端是否通过 URL 调用调整大小？随机化发送给它们的 URL 中的服务器名称。业务层调用调整大小？在那里随机化服务器名称。）。

如果您需要更具体的答案，请提供更多详细信息。

于 2013-01-11T17:07:03.950 回答