问题标签 [capacity-planning]

一台 Web 服务器可以处理多少流量？看看我们是否超出这个范围的最好方法是什么？

我有一个拥有几百个用户的 ASP.Net 应用程序。它的某些方面是相当密集的处理器，但到目前为止，我们已经做得很好，只有一台服务器来运行 SqlServer 和站点。它运行 Windows Server 2003，3.4 GHz 和 3.5 GB 的 RAM。

但是最近我开始注意到在不同的时间变慢了，我想知道确定服务器是否因应用程序的使用而过载或者我是否需要做一些事情来修复应用程序的最佳方法是什么（我不如果我对盒子的期望过高，我真的想花很多时间寻找一些小的优化）。

虽然估计直线行和表大小是相当简单的数学运算，但我们发现猜测每个索引将占用多少空间（对于给定的表大小）具有挑战性。我们可以学习哪些领域来计算指数的更好估计和增长率？

我们有一个很快需要部署的 ASP.NET 项目（大约 40 个 Web 表单、50 个表、相当标准的 IO 内容，并注意尽可能减少）。系统上将有大约 100 个并发用户，但任何时候只有大约 20 个用户会对其进行攻击。我们最初将在 32 位的 Windows Server 2008 上部署它。

在考虑生产服务器规格时，我们应该更担心的是，获得更多内核和更少内存（例如 4 核和 4mb）还是更多内存和更少内核（2 核和 8mb）？

升级到 Windows Server 64 位是否有助于提高内存利用率？

我的 SQL 数据库中的一张表的增长率为每纳秒两个半字节。我想知道每天有多少兆字节，我应该担心吗？我的硬盘是 150 GB。

我正在做一些工作来分析来自 Catalyst Web 应用程序的访问日志。数据来自网络场前面的负载均衡器，每天总计约 35Gb。它存储在Hadoop HDFS 文件系统中，我使用 MapReduce（通过Dumbo，这很棒）来处理数字。

分析的目的是尝试建立使用配置文件——哪些操作使用最多，每个操作的平均响应时间是多少，响应是从后端还是缓存提供的——用于容量规划、优化和设置监控系统的阈值。像 Analog 这样的传统工具会为我提供请求最多的 URL 或最常用的浏览器，但这些对我来说都没有用。我不需要知道那/controller/foo?id=1984是最流行的 URL；我需要知道所有命中的命中率和响应时间是多少，/controller/foo以便我可以查看是否有优化或缓存的空间，并尝试估计如果此操作的命中突然翻倍可能会发生什么。

我可以通过 MapReduce 轻松地将数据分解为每个时间段每个操作的请求。问题是以易于理解的形式显示它并挑选出重要的趋势或异常。我的输出形式为：

即，键是时间段，值是(action, hits, cache hits)每个时间段的元组。（我不必坚持这一点；这就是我到目前为止所拥有的。）

大约有 250 个动作。它们可以组合成较少数量的组，但在同一个图表上随时间绘制每个操作的请求数量（或响应时间等）可能不起作用。首先，它太吵了，其次，绝对数字并不重要——对于经常使用的、轻量级、可缓存的响应的请求，每分钟增加 100 个请求远不如每分钟增加 100 个请求重要在一个很少使用但昂贵（可能会命中数据库）不可缓存的响应中。在同一张图表中，我们不会看到很少使用的操作的请求变化。

静态报告不太好——一个巨大的数字表很难消化。如果我按小时汇总，我们可能会错过重要的每分钟更改。

有什么建议么？你是如何处理这个问题的？我想一种方法是以某种方式突出每个操作的请求率或响应时间的重大变化。滚动平均值和标准偏差可能会显示这一点，但我可以做得更好吗？

我还能生成哪些其他指标或数据？

我阅读和体验过的所有内容（基于 Tornado 的应用程序）都让我相信 ePoll 是基于 Select 和 Poll 的网络的自然替代品，尤其是 Twisted。这让我很偏执，因为一种更好的技术或方法不付出代价是非常罕见的。

阅读 epoll 和替代方案之间的几十个比较表明，epoll 显然是速度和可扩展性的冠军，特别是它以线性方式扩展，这太棒了。也就是说，处理器和内存利用率如何，epoll 仍然是冠军吗？

我经常被要求为我们的客户进行规模和容量规划。当我们的客户购买我们的产品（基本上是 J2EE Web 应用程序）时，他们经常会问他们需要什么硬件来运行这些产品。我们的建议通常会导致高成本的硬件采购。

到目前为止，我开发的最佳启发式方法是将利用率预测（应用程序应该参与的注册用户和并发用户的数量）与我们现有安装中收集的数据进行比较。类似于：如果安装 A 使用 X 硬件参加 100 个并发用户，那么安装 B 将需要 2*X 硬件来参加 200 个并发用户。

然而，这种方法存在许多问题。客户经常使用不同的硬件和软件平台。他们从我们这里购买的产品集通常不会相同，并且通常部分应用程序是根据特定客户的订单构建的。考虑到软件版本正在发生变化等，并且有很多参数可以使调整大小的任务变得非常困难。

我研究了一些关于该主题的书籍，有些建议使用复杂的数学模型。这些方法需要作为输入的参数数量（例如应用程序功能的详细分类）使我认为这些几乎没有用。硬件通常在定义基本要求之前就已订购，更不用说这些在应用程序开发和生命周期中会有所不同。那么，您如何进行规模和容量规划呢？任何提示和操作方法表示赞赏。

我希望能够记录 FFMPEG 进程，因为我正在尝试计算一分钟的视频转换需要多长时间，以帮助我的视频编码服务器的容量规划。如何启用日志记录以及日志文件保存在哪里。我在 CentOS LAMP 机器上安装了 FFMPEG。

假设，我想开发堆栈溢出网站。假设每天有 100 万个请求，我如何估算支持该网站所需的商品硬件数量。是否有任何案例研究可以解释这种情况下可能的性能改进？

我知道 I/O 瓶颈是大多数系统的主要瓶颈。提高 I/O 性能的可能选项有哪些？我认识的几个是

1. 缓存
2. 复制

我正在为低延迟应用程序进行一些性能调整和容量规划，并且有以下问题：

在伦敦的主机和纽约的主机之间通过光纤连接发送的数据包的理论最短往返时间是多少？