我刚刚阅读了这本书The Art of Capacity planning（顺便说一句，我喜欢它），作者在其中解释了衡量服务，找出最高限度，预测需求，确保随和部署等方面的重要性。但是，通过这本书，他解释了他在Flickr的经历，他不得不面对同样的产品。
我们很多人，我们在其他公司面临中小型项目规模的公司工作。我们必须了解他们的业务，他们的需求，计划架构，模型等等。
然后，客户说“我需要支持1000个用户”。那么，每秒有多少请求是用户？他们的会议有多长？他们传输了多少数据？他们执行哪些操作？他们有多久了？
有时可以了解这些数据（监控他们现有的应用程序或因为他们已经完成了测量），有时候这是不可能的（因为他们没有当前的网站，或者只是可能知道）。
您如何猜测服务器数量，带宽，存储空间等...您使用哪些参考数据？
问候。
答案 0 :(得分：21)
进行此规划需要了解的一些要点
平均数字可以让您知道每月需要什么。对于cource，您还需要考虑峰值数字 - 但是当他们撕毁Web服务器计算机和站点时，他们会按月提供带宽并在硬盘上提供几千兆字节，因此峰值在开始时不是问题。在那里你必须认为，如果你运行需要太多ram的sql查询，或者你与许多其他站点共享计算机。
对于网站，没有经验，你没有实际的措施。 没有措施，你实际上不能确定，但你可以遵循一些指南
try to make the grow of your data/features/runs linear and not logarithmic。The speed of your site is not (only) depend from the capacity and the speed of your computer。仅在计算机处于极限时才依赖。如果计算机达到其限制，则添加其他资源。但是，在设计软件时，速度必须要小心，而且速度快的软件也要花费成本。我们的目标是拥有所有这些，并且优先考虑您首先关注的内容。
Performance and Capacity: Two diffident animals*。性能基于更多的人工工作，并且容量基于更多的计算机资源。为了提高速度，首先需要知道如何使计算机平稳快速地运行，然后知道如何使程序快速运行，特别是网络上的程序，然后你实际上需要花更多的时间来实际运行运行后的程序，以提高它在关键领域的表现。
进行良好的软件设计并注意扩展的可能性，以防您可能需要更多，以便为您的客户提供从少开始的机会，并且只有在需要时才支付更多费用。因此，当您设计软件时，请考虑将其用于Web池，注意同步，处理公共资源，提供从不同服务器获取数据的能力等。
好吧，假设客户说只有1000个用户并且没有有趣的nether用于扩展，nether用于速度，并且只需要一个具有成本效益的站点来完成他的工作。在这种情况下，您还可以使用此限制进行设计。这有什么限制。您不会对同步进行数十次检查，并使其像单个线程，单池程序一样工作。您不使用任何互斥，任何双重检查，任何认为当您有2个池或2台计算机运行相同的应用程序时发生。您只需注意在需要升级的情况下更改它们的代码点。
您也没有制作任何使用多计算机资源的代码。当你运行它时，你要注意只在一个池下运行才能正常工作。
这个单池设计更容易开发，更容易调试，易于控制，易于更新错误代码，成本更低，但速度快（一个用户在另一个线程池上等待另一个）并且不能在资源上扩展，实际上也必须与速度有关。
如果您不知道自己拥有多少用户，可以使用alexa查看与您相似的网站以及他们每月的平均用户数和平均网页浏览量。然后你可能知道可能的带宽。
从您对硬件的预测开始，但不要从第一天开始租用2台计算机。从第一个开始，制定措施，查看数据如何增长，并且只在需要时展开它。
当程序运行时，如果你遵循它，你会发现许多人认为需要纠正。我可以说你生命中只有两个。
我们将程序置于在线后，我们的客户开始添加数据。几个月之后，我们注意到数据库增长太多了 - 我们没想到数据会输入。我们花了差不多一个星期来找到原因并修复它，这是一个设计错误，使一些统计数据变得对数增长，我们纠正它并继续前进。
经过两年的运行，我们注意到我们对SQL服务器进行了太多不必要的调用。我们追查它并再次发现设计错误，我们纠正它并继续前进。
实际上，我们每个月都会发现并修复许多小点。对我来说就像公式一样。你决定你拥有什么样的汽车，一个需要所有时间校正以获得最大值的公式，或者只需要每年服务的简单汽车？
Then, the customer says "I need to support 1000 users"客户不知道编程，并试图从他的角度找到一个衡量标准来比较提案。实际上这里有更多的因素，1000个用户不是一个正确的参数。每分钟每月或每月1000个用户？需要通过实时聊天来支持，还是需要查看大量数据，还是需要快速工作？所以也许你可以通过向他解释一个好的程序对一百万用户的一个用户来说是好的，并且实际上它的开始是开发成本而不是用户。
现在，如果这是一个实际规划网站的问题，那么简单的终点答案是开始做，其余的将被揭示。如果这是一个问题，因为你为自己的客户搜索答案，那么你必须问问自己：为什么一级方程式赛车只能坐一个而你的车可以装五个？或者电影花了多少钱？或者我们都知道如何写，但为什么不是我们所有人都写和出版一本书？我的观点是，成本实际上来自于您花费在制作项目上的时间，而他自己的用户无法确定。
<猜测，知识还是预测？ How do you make a guess about the number of servers, bandwidth, storage, etc...我们实际上没有猜测，我们有很多网站，我们每天都会自动收集许多统计数据，多年经验，而且我们从网站内容中了解到，每天有多少用户可以拥有很多带宽可以吃。我们还有许多在我们的服务器上运行的数据库，我们可以看到它们使用了多少数据。 99％的网站都是低数字。所以这是知识和经验，有真实的实时统计数据。通过监控流量及其使用情况来预测，我们会尝试让它们更好，以获得更多流量，更多用户，以及我们存档的内容，我们会尝试预测未来是否需要更多资源。此外，99％的网站都是单一游泳池，运行非常简单的演示文稿。
＆＃39; *从书中
答案 1 :(得分：8)
这通常非常困难，因为当客户要求回答这个问题时，系统甚至都没有设计。这在法律上是不可能的。
作为一个非常粗略的经验法则，我们每台服务器每秒使用100个请求。实际数量将根据应用程序和用户使用系统的方式而有所不同，但我们发现这是一个很好的初步估计。
文档系统的磁盘使用量只是文档数乘以平均大小。带宽是请求数乘以平均请求数。
您只需记录所有假设，并说硬件要求基于这些假设。
答案 2 :(得分：4)
在开发最近的Asp.Net MVC网站时，我使用selenium来加载测试我的网站。 基本上，您可以记录一系列宏，您可以在其中执行随机任务。
然后使用selenium来模拟执行这些宏的许多用户。 我用数十，数百甚至数千名用户测试了我的网站。 这使您可以在上线前找到代码和基础设施中的故障点。
答案 3 :(得分：4)
which figures of reference do you use?
实际上只需要查看一个数字，然后推断：数据。所有数据均来自数据要求。
小例子：8字节二进制数每小时十亿次请求不会崩溃，可以从最简单的Web服务器运行。原因是请求时间将是几分之一毫秒。一天内有1000（ms / s）* 60（s / m）* 60（m / h）* 24（h / d）= 8640万毫秒，这意味着即使每个请求花费了整整一毫秒100万所需的速度仍然可用，因为获得8个字节所需的速度将在8kb / s范围内。
真实版本：查看数据将确定要求，并且正在检索的数据几乎总是在数据库中。数据库的设计（即使在概念上）可以帮助确定将使用多少数据。现实生活中有多种要求。应检查数据库或文件系统的最大容量。通过总计每列所消耗的总空间，可以通过查看表的每一行需要多少空间来计算该容量（即int类型的id与长度6的id将占用6个字节或空间）。在对表的一行的每一列求和之后，对于数据库中的每个表，将很容易分辨每个表集合需要多少内存（通常表通过外键链接）。在考虑表内存消耗之后，必须检查用户的要求。主要感兴趣的是每个用户每个会话将访问多少个表（没有数据这将是一个猜测 - 最好高估）。因为我们已经知道或者有一个好主意，所以数据库表的大小是多少，我们可以假设用户需要多少服务器内存。将此内存使用量与预期用户数量进行比较将有助于确定要使用的服务器数量或数量。接下来要弄清楚的是，由于用户操作，将有多少表（再次，平均猜测或某些收集的测试数据）插入到数据库中。这非常具有推测性，最好通过测试来完成。如果不进行测试，假设应该被高估。根据每个用户将插入多少行，可以推断数据库大小和带宽要求。这些将通过将一个用户的数据需求扩展到每t时间n个用户的要求来确定。 n个用户所需的数据可以在一段时间内查看带宽需求，还可以确定n个用户如何在一段时间内扩展数据库。
答案 4 :(得分：3)
在实践中，我们没有。我们确保能够快速扩展（devops），有可能回退到使用更少的资源/请求，从少数用户开始并观察性能。大多数中小型项目都不想花太多时间和金钱。对于大型或关键项目，创建和运行模拟是有意义的。
请记住，有一天计划成本与一年的额外机器一样多。
答案 5 :(得分：2)
您使用容量来涵盖系统的许多非功能性质，并且可能试图将性能，容量和可伸缩性纳入其中一个概念。
让我们从性能开始，如果您正在处理基于Web的架构，那么您正在为资源提供服务，那么这非常简单，可以分为两个不同的KPI;服务器响应时间和页面加载时间（应该称为资源加载时间，因为并非Web上的所有资源都是网页）。
服务器响应时间测量给定资源上请求的最后一个字节的时间。请注意，这不包括内容协商等内容。您（或业务）需要为给定类型的资源指定预期的服务器响应时间。这基于单个请求/响应，例如对属于“汽车模型”类型的任何资源的请求的响应，应该花费不超过0.5秒，时间到最后一个字节。
页面加载时间更进一步。给定资源请求，加载该资源需要多长时间，以及任何相关资源。在Web页面的上下文中它确实有更多的意义。网络充满了未知数，这使得这有点像灰色区域，因为各种各样的东西在这个（网络，客户端，内容协商）上发挥作用所以你需要精确的这给定一个固定/稳定的网络和客户端（有各种各样的工具来实现这一目标）。它也应该始终定义为平均值，而不会引入并发问题（我们仍然没有考虑容量）。
一旦指定了两者，就可以开始确定系统的即时容量，即每秒可以为资源做出多少请求（如上所述）。有很多工具可以帮助您定义它。这将为您提供即时的容量测量。您会注意到我使用术语“立即”，因为通常业务可能会转而说，很好，但如果我们需要增加此容量会发生什么。
因此，我们进入第三个非功能性，可扩展性（n.b，系统有超过3个非功能性质，包括可用性，可靠性，有效性，可用性，可访问性，可扩展性和可管理性）。给定一定的容量，我可以在多大程度上提高它的性能。还有各种方法可以增加容量，但是大多数设计系统通常都会产生一个瓶颈，造成约束。