我刚刚阅读了《容量规划的艺术》（顺便说一句，我喜欢它）这本书，作者在书中解释了衡量服务、找出上限、预测需求、确保轻松部署等的重要性。等等。 . 但是通过这本书，他解释了他在 Flickr 的经历，在那里他必须始终面对相同的产品。
我们中的很多人，我们在面对其他公司的中小型项目的公司工作。我们必须了解他们的业务、他们的需求、规划架构、模型等......等等。
然后，客户说“我需要支持 1000 个用户”。那么，一个用户每秒有多少个请求？他们的会议时间有多长？他们传输了多少数据？他们执行哪些操作？他们多久了？
有时可能知道这些数字（监控他们现有的应用程序或因为他们已经完成了测量），有时不可能（因为他们没有当前的网站，或者只是可能知道）。
您如何猜测服务器的数量、带宽、存储等……您使用哪些参考数据？
问候。
制定此计划需要了解的一些要点
平均数字可以让您了解您每月需要什么。当然，您还需要考虑峰值数字 - 但是当他们租用 Web 服务器计算机和站点时，他们会按月提供带宽和一些千兆字节的硬盘，因此峰值在起点不是问题。在那里，您必须认为如果您运行需要太多内存的 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 个用户并且对扩展和速度不感兴趣，只需要一个具有成本效益的网站来完成他的工作。在这种情况下，您还可以使用此限制进行设计。这是什么限制。您不需要对同步进行数十次检查，而是让它像单线程、单池程序一样工作。当您有 2 个池或 2 台计算机运行相同的应用程序时，您不会使用任何互斥锁、任何双重检查或任何想法。您只需注意在需要升级的情况下更改它们的代码点。
您也没有编写任何使用多计算机资源的代码。当您运行它时，请注意仅在一个池下运行才能正常工作。
这种单池设计更易于开发，更易于调试，易于控制，易于更新错误代码，成本更低，但速度（一个用户在一个线程池上等待另一个用户）并且无法扩展资源，这实际上也与速度有关。
如果您不知道您可能拥有多少用户，您可以使用 alexa 查看与您的网站相似的网站以及他们每月的平均用户/平均页面浏览量。然后你可能知道可能的带宽。
从你对硬件的预测开始，但不要从第一天起就去租两台电脑。从第一个开始，制定衡量标准，了解数据如何增长，并仅在需要时对其进行扩展。
当程序运行时，如果您遵循它，您会发现许多需要纠正的想法。我可以说你只有我生命中的两个。
在我们将程序上线后，我们的客户开始添加数据。几个月后，我们注意到数据库增长过多——这是我们从输入的数据中没有预料到的。我们花了将近一周的时间来找出原因并修复它，这是一个设计错误，使一些统计数据变成对数，我们纠正它并继续前进。
经过两年的运行，我们注意到我们对 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% 的站点都是运行非常简单的演示文稿的单池。
'* 从书中
这通常是非常困难的，因为当客户询问这个问题的答案时，甚至没有设计系统。这实际上是不可能的。
作为一个非常粗略的经验法则，我们每台服务器每秒使用 100 个请求。实际数量将根据应用程序和用户使用系统的方式而有所不同，但我们发现这是一个很好的初步估计。
文档系统的磁盘使用量只是文档数量乘以平均大小。带宽是请求数乘以请求的平均大小。
您只需记录所有假设并说硬件要求基于这些假设。
在开发最近的 Asp.Net MVC 站点时，我使用selenium对我的站点进行负载测试。基本上，您录制了一系列宏，您可以在其中执行随机任务。
然后使用 selenium 模拟一些执行这些宏的用户。我用数十、数百甚至数千名用户测试了我的网站。这使您可以在上线之前发现代码和基础设施中的问题点。
which figures of reference do you use?
实际上只有一个数字需要查看，然后推断：数据。所有数字都来自数据要求。
小例子：每小时 10 亿次对 8 字节二进制数的请求不会导致任何崩溃，并且可以从最简单的 Web 服务器上运行。这样做的原因是请求时间将是几分之一毫秒。一天有 1000 (ms/s) * 60 (s/m) * 60 (m/h) * 24 (h/d) = 8640 万毫秒，这意味着即使每个请求花费了整整一毫秒，这 100 万required 仍然可用，因为获取 8 个字节所需的速度将在 8kb/s 范围内。
现实版：查看数据将确定需求，并且正在检索的数据几乎总是在数据库中。数据库的设计（即使在概念上）可以帮助确定将使用多少数据。现实生活中有多种需求。应检查数据库或文件系统的最大容量。这个容量可以通过查看表的每行需要多少空间来计算，通过总结每列消耗的总空间（即长度为 6 的 int 类型的 id 将占用 6 个字节或空间）。在对表的一行的每一列求和后，对于数据库中的每个表，很容易知道每个表集合需要多少内存（通常表是通过外键链接的）。考虑到表内存消耗后，然后必须检查用户的要求。主要感兴趣的是每个用户将在每个会话中访问多少表（没有数据，这将是一个猜测 - 最好高估）。因为我们已经知道或有一个好主意，数据库表的大小是多少，我们可以假设用户需要多少服务器内存。将此内存使用量与预期用户数量进行比较将有助于确定使用哪个服务器或使用多少。接下来要计算的是，由于用户操作，将有多少表（同样，平均猜测，或一些收集的测试数据）插入数据库。这是非常投机的，最好通过测试来完成。如果没有测试，假设应该被高估。根据每个用户将插入的行数，可以推断数据库大小和带宽要求。这些将通过将一个用户的数据需求扩展到每t时间n个用户的需求来确定。n 个用户所需的数据可以查看 t 时间内的带宽需求，并且还将确定 n 个用户将如何在 t 时间内增长数据库。
在实践中，我们没有。我们确保我们能够快速扩展（devops），有可能退回到使用更少的资源/请求，从极少数用户开始并观察性能。大多数中小型项目不想在这方面花费太多时间和金钱。对于大型或关键项目，创建和运行模拟是有意义的。
请记住，一天的计划成本与一年的额外机器成本一样多。
您使用容量来涵盖系统的许多非功能特性，并且可能试图将性能、容量和可伸缩性封装到一个概念中。
让我们从性能开始，如果您正在处理基于 Web 的架构，您在其中提供资源，那么这真的非常简单，可以分为 2 个不同的 KPI；服务器响应时间和页面加载时间（应该称为资源加载时间，因为并非网络上的所有资源都是网页）。
服务器响应时间测量对给定资源的请求到最后一个字节的时间。请注意，这不包括内容协商等内容。您（或企业）需要为给定类型的资源指定预期的服务器响应时间。这基于单个请求/响应，例如对属于“汽车模型”类型的任何资源的请求的响应，应该不超过 0.5 秒，即到最后一个字节的时间。
页面加载时间更进一步。给定对资源的请求，加载该资源以及任何相关资源需要多长时间。在网页的上下文中，它确实具有更多的意义。网络充满了未知数，这使得这有点像一个灰色区域，因为各种各样的事情都会在这个领域发挥作用（网络、客户端、内容协商），所以你需要在给定一个固定/稳定的网络和客户端的情况下具体说明这一点（有各种各样的工具可以实现这一点）。它也应该始终定义为平均值，而不引入并发问题（我们还没有考虑容量）。
一旦您指定了两者，您就可以开始确定系统的即时容量，即我每秒可以高效地发出多少资源请求（如上所述）。有很多工具可以帮助您定义这一点。这将使您立即衡量容量。您会注意到我使用“立即”一词是因为业务经常会转身说，太好了，但是如果我们需要增加这种容量会发生什么。
所以我们转向第三个非功能性，可扩展性（注意，系统有超过 3 个非功能性品质，包括可用性、可靠性、有效性、可用性、可访问性、可扩展性和可管理性）。给定一定的容量，我可以在性能上增加多少。还有各种增加容量的方法，但大多数系统的设计通常在某个地方存在瓶颈，从而产生限制。