您如何进行网站容量规划? [关闭]

Posted

技术标签:

【中文标题】您如何进行网站容量规划? [关闭]【英文标题】:How do you do website capacity planning? [closed] 【发布时间】:2012-02-22 08:29:41 【问题描述】:

我刚刚阅读了The Art of Capacity planning 这本书(顺便说一句,我喜欢它),作者在书中解释了衡量您的服务、找出您的上限、预测您的需求、确保轻松部署等的重要性。等等.. 但是通过这本书,他解释了他在 Flickr 的经历,在那里他必须一直面对同一个产品。

我们中的很多人都在面临其他公司的中小型项目的公司工作。我们必须了解他们的业务、他们的需求、规划架构、模型等......等等。

然后,客户说“我需要支持 1000 个用户”。那么,一个用户每秒有多少个请求?他们的会议时间有多长?他们传输了多少数据?他们执行哪些操作?他们有多长?

有时可能知道这些数字(监控他们现有的应用程序或因为他们已经完成了测量),有时不可能(因为他们没有当前的网站,或者只是可能知道)。

您如何猜测服务器的数量、带宽、存储等...您使用哪些参考数据?

问候。

【问题讨论】:

这可能应该在 webmasters.***.com 上。 【参考方案1】:

这通常非常困难,因为当客户询问此问题的答案时,系统甚至还没有设计好。这实际上是不可能的。

作为一个非常粗略的经验法则,我们每台服务器每秒使用 100 个请求。实际数量会因应用程序和用户使用系统的方式而异,但我们发现这是一个不错的初步估计。

文档系统的磁盘使用量只是文档数量乘以平均大小。带宽是请求数乘以平均请求大小。

您只需记录所有假设并说硬件要求基于这些假设。

【讨论】:

这就是我想要的,一个我可以作为参考的数字。即使它不准确,或者它是粗略的,但可以做出初步的粗略猜测。【参考方案2】:

制定此计划需要了解的一些要点

    每天有多少用户。 您要控制多少数据。 您要向每个用户显示多少数据。 可能需要的平均用户带宽。 用户使用您网站的平均时间。

平均数字可以说明您每月需要什么。当然,您还需要考虑峰值数字 - 但是当他们租用 Web 服务器计算机和站点时,他们会按月提供带宽和一些千兆字节的硬盘,因此峰值在起点不是问题。在那里你必须想到如果你运行需要太多内存的 sql 查询,或者如果你与许多其他站点共享计算机。

测量

没有网站,没有经验,你就没有实际的措施。 如果没有措施,您实际上无法确定,但您可以遵循一些指南

不管你做什么,try to make the grow of your data/features/runs linear and not logarithmicThe speed of your site is not (only) depend from the capacity and the speed of your computer。仅当计算机处于他的极限时才依赖。如果计算机达到他的极限,你添加额外的资源。但是在设计软件时必须注意速度,而且速度好的软件也是要花钱的。 您的数据库中每天都有数百万条数据吗?你需要更多的内存和硬盘 您有视频和许多大文件要发送吗?您需要更多带宽。 您有使用该网站工作的人吗?您需要更快的速度和稳定性 您是否再制作一个电子商务网站?您需要更高的安全性和稳定性

目标是拥有所有这些,而您首先关注的重点实际上会发生变化。

规划速度。

Performance and Capacity: Two diffident animals*。性能基于更多的人工工作,而容量基于更多的计算机资源。要让它速度你首先需要知道如何让计算机运行流畅和快速,然后知道如何让程序运行得很快,特别是网络上的程序,然后你实际上需要花更多的时间来实际运行。运行后的程序,以提高其在关键领域的性能。

计划扩展。

做好软件设计并注意扩展的可能性,以防您可能需要更多,以便让您的客户有机会从小事做起,只在他需要时支付更多费用。因此,当您设计您的软件时,您应该像在网络池中使用它一样,注意同步、处理公共资源、提供从不同服务器获取数据的能力等。

有限制地规划

好吧,假设客户说只有 1000 个用户,并且对扩展和速度不感兴趣,只需要一个具有成本效益的网站来完成他的工作。在这种情况下,您还可以使用此限制进行设计。这是什么限制。您不需要对同步进行数十次检查,而是让它像单线程、单池程序一样工作。当您有 2 个池或 2 台计算机运行相同的应用程序时,您不会使用任何互斥锁、任何双重检查或任何想法。您只需注意代码点以在需要升级的情况下更改它们。

您也没有编写任何使用多计算机资源的代码。当你运行它时,你要注意它只在一个池下运行才能正常工作。

这种单池设计更易于开发,更易于调试,易于控制,易于更新有缺陷的代码,成本更低,但速度较慢(一个用户在一个线程池上等待另一个用户)并且不能资源扩张,其实也和速度有关。

查找统计数据

如果您不知道您可能拥有多少用户,您可以使用 Alexa 查看与您的网站相似的网站以及他们每月的平均用户/平均页面浏览量。然后你可能知道可能的带宽。

在需要之前不要购买

从对硬件的预测开始,但不要从第一天起就去租两台电脑。从第一个开始,制定衡量标准,查看数据如何增长,并仅在需要时对其进行扩展。

汽车还是一级方程式?

当程序运行时,如果你跟随它,你会发现许多需要纠正的想法。我可以说你在我的生活中只有两个。

在我们将程序上线后,我们的客户开始添加数据。几个月后,我们注意到数据库增长过多——这是我们从输入的数据中没有预料到的。我们花了将近一周的时间来找出原因并修复它,这是一个设计错误,导致一些统计数据变成对数,我们更正它并继续前进。

经过两年的运行,我们注意到我们对 SQL Server 进行了太多不必要的调用。我们追踪它并再次发现一个设计错误,我们纠正它并继续前进。

实际上,我们每个月都发现并修复了许多性能小点。对我来说,它就像一级方程式。你决定你有什么车,一辆需要一直修正以获得最大性能的方程式,还是一辆只需要每年保养一次的简单车?

客户观点

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% 的网站都是运行非常简单的演示文稿的单池。

'*来自书本

【讨论】:

嗯。对于容量规划,我想说我想知道峰值数量,而不是平均值。 @StephanEggermont 我认为如果您计划该站点将使用 100Mg,那么您现在将获得 3 Gb 磁盘与服务器。 谢谢,这是对书中内容的简要介绍。 @vtortola 您的意见受到尊重。怎么从来不看书,随便看看,其余的都是我的工作和知识。祝您的客户好运。 @vtortola 正如我告诉你的那样,你的意见受到尊重,我实际上试图用爱来帮助这里,并且仍然继续提供帮助而不期待任何事情。我的上师让我走上了爱的道路:)一切都是爱和美好的,生活是美好的,当我提供任何帮助时,我感觉很酷。 :)))【参考方案3】:

在开发最近的 Asp.Net MVC 站点时,我使用 selenium 对我的站点进行负载测试。 基本上,您录制了一系列宏,您可以在其中执行随机任务。

然后使用 selenium 模拟一些执行这些宏的用户。 我用数十、数百甚至数千名用户测试了我的网站。 这使您可以在上线之前发现代码和基础架构中的问题点。

【讨论】:

+1 for selenium,非常好的测试环境【参考方案4】:

实际上,我们没有。我们确保我们能够快速扩展(devops),有可能退回到使用更少的资源/请求,从极少数用户开始并观察性能。大多数中小型项目不想在这方面花费太多时间和金钱。对于大型或关键项目,创建和运行模拟是有意义的。

请记住,一天的计划成本与一年的额外机器成本一样多。

【讨论】:

【参考方案5】:

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 时间内增长数据库。

【讨论】:

不好,不好的例子。你知道请求的大小是多少字节吗?反应有多大?即使它只包含一个字节的有效载荷?以及建立 http 连接所需的数据包数量? 请求/响应以及“建立 http 连接”肯定是对 TCP 握手的引用。由于握手的占用空间在实际使用中往往是微不足道的,所以它没有包含在 small 示例中。 这使它成为一个不好的例子,因为那里的连接足迹会限制你的可扩展性(远低于 10 亿个请求/小时) 所以你的意思是没有人可以每小时处理十亿个请求?准确地说是每毫秒 277 个。我会假设像谷歌这样的地方最终会以这种速度为请求提供服务。因此,这使您对每小时达到十亿个请求的能力的观点变得毫无意义。连接足迹.. 不幸的是,这不是一个真正的技术术语,在那种情况下无关紧要。最重要的是可用于连接到数据库或缓存服务器的连接线程总数,以及这些线程的重用频率。您的评论含糊不清,无法认真对待。【参考方案6】:

您使用容量来涵盖系统的许多非功能性品质,并且可能试图将性能容量可扩展性封装到一个概念。

让我们从性能开始,如果您正在处理基于 Web 的架构,您在其中提供资源,那么这真的非常简单,可以分为 2 个不同的 KPI;服务器响应时间和页面加载时间(应称为资源加载时间,因为并非网络上的所有资源都是网页)。

服务器响应时间测量对给定资源的请求到最后一个字节的时间。请注意,这不包括内容协商等内容。您(或企业)需要为给定类型的资源指定预期的服务器响应时间。这是基于单个请求/响应,例如对属于“汽车模型”类型的任何资源的请求的响应,应该不超过 0.5 秒,即最后一个字节的时间。

页面加载时间更进一步。给定对资源的请求,加载该资源以及任何相关资源需要多长时间。在网页的上下文中,它确实具有更多意义。网络充满了未知数,这使得这有点像一个灰色地带,因为各种各样的事情都会在这个领域发挥作用(网络、客户端、内容协商),所以你需要在给定一个固定/稳定的网络和客户端的情况下具体说明这一点(有各种各样的工具可以实现这一点)。它也应始终定义为平均值,而不会引入并发问题(我们还没有考虑容量)。

一旦您指定了两者,您就可以开始确定系统的即时容量,即我每秒可以高效地发出多少资源请求(如上所述)。有很多工具可以帮助您定义这一点。这将使您立即衡量容量。您会注意到我使用“立即”一词是因为业务经常会转身说,很好,但是如果我们需要增加这种容量会发生什么。

所以我们转向第三个非功能性,可扩展性(n.b,系统有超过 3 个非功能性品质,包括可用性、可靠性、有效性、可用性、可访问性、可扩展性和可管理性)。给定一定的容量,我可以在性能上增加多少。还有多种方法可以增加容量,但大多数系统在设计上通常会在某个地方出现瓶颈,从而产生限制。

【讨论】:

以上是关于您如何进行网站容量规划? [关闭]的主要内容,如果未能解决你的问题,请参考以下文章

实践分享丨企业上云后资源容量如何规划和实施

最佳实践丨企业上云后资源容量如何规划和实施

浅谈容量测试与容量规划

阿里研究员蒋江伟:全链路压测是双11容量规划利器

K8S集群容量规划: 容量规划系列2

K8S集群容量规划: 容量规划系列2