如何对网站进行负载测试和容量规划?

如何对网站进行负载测试和容量规划?

这是一个典型问题关于网站容量规划。

有关的:

有哪些针对网站和网络应用程序容量规划的推荐工具和方法?

请随意描述针对不同网络服务器、框架等的不同工具和技术,以及适用于一般网络服务器的最佳实践。

答案1

简短的回答是:除了你之外没有人可以回答这个问题。

长话短说,对你的具体工作量进行基准测试是你需要自己做的事情,因为这有点像问“一根绳子有多长?”。

一个简单的单页静态网站可以托管在 Pentium Pro 150 上,并且每天仍然可以提供数千次展示。

回答这个问题的基本方法是尝试看看会发生什么。您可以使用许多工具来人为地对系统施加压力,看看它会在何处弯曲。

简要概述如下:

  • 将您的场景放在适当位置
  • 添加监控
  • 添加流量
  • 评估结果
  • 根据结果​​进行补救
  • 冲洗,重复,直到满意为止

将您的场景放在适当位置

基本上,为了测试一些负载,您需要一些测试对象。设置一个测试环境。如果可能的话,这应该是与您的生产硬件相当接近的猜测,否则您将只能推断您的数据。

设置您的服务器、帐户、网站、带宽等。即使您在虚拟机上执行这些操作也是可以的,只要您准备好扩展您的结果。

因此,我将设置一个中等功率的虚拟机(两个核心,512 MB RAM,4 GB HDD)并安装我最喜欢的负载平衡器,haproxy里面红帽Linux在虚拟机上。

我还将使用两台 Web 服务器来对负载均衡器进行压力测试。这两台 Web 服务器的设置与我的实时系统完全相同。

添加监控

您需要一些指标来监控,因此我将测量有多少请求到达我的 Web 服务器,以及在用户开始获得超过两秒的响应时间之前每秒我可以挤过多少个请求。

我还将监控haproxy实例上的 RAM、CPU 和磁盘使用情况,以确保负载均衡器可以处理连接。

如何做到这一点很大程度上取决于您的平台,超出了本回答的范围。您可能需要查看 Web 服务器日志文件、启动性能计数器或依赖压力测试工具的报告功能。

您始终需要监视以下几件事:

  • CPU使用率
  • RAM 使用情况
  • 磁盘使用情况
  • 磁盘延迟
  • 网络利用率

根据具体测试的内容,您可能还会选择查看 SQL 死锁、寻道时间等。

添加流量

事情变得有趣了。现在你需要模拟一个测试负载。很多工具可以做到这一点,具有可配置选项:

选择一个数字,任意数字。假设您要查看系统在每分钟 10,000 次点击下如何响应。选择什么数字并不重要,因为您要重复此步骤多次,上下调整该数字以查看系统如何响应。

理想情况下,您应该将这 10,000 个请求分布到多个负载测试客户端/节点上,以便单个客户端不会成为请求的瓶颈。例如,JMeter 的远程测试提供一个中央界面,可以从控制 Jmeter 机器启动多个客户端。

按下魔法按钮并观察你的网络服务器是否崩溃。

评估结果

因此,现在您需要返回到您在步骤 2 中收集的指标。您会发现,在 10,000 个并发连接的情况下,您的haproxy机器几乎不会出任何问题,但两个 Web 服务器的响应时间却超过了五秒。这可不妙 - 请记住,您的响应时间目标是两秒。因此,我们需要进行一些更改。

补救

现在,您需要将网站速度提高一倍以上。因此,您知道您需要扩大规模或扩展规模。

要扩大规模,需要获取更大的网络服务器、更多的 RAM 和更快的磁盘。

要扩展,请获取更多服务器。

使用步骤 2 中的指标和测试来做出此决定。例如,如果您在测试期间发现磁盘延迟很大,则您知道需要扩大规模并获得更快的硬盘。

如果您发现处理器在测试期间处于 100%,则可能需要扩展以添加其他 Web 服务器,以减轻现有服务器的压力。

没有通用的正确或错误答案,只有适合您的答案。尝试扩大规模,如果不行,则扩大规模。或者不扩大规模,这取决于您和一些跳出框框的思维。

假设我们要扩展。因此我决定克隆我的两个 Web 服务器(它们是虚拟机),现在我有四个 Web 服务器。

重复

从第 3 步重新开始。如果您发现事情没有按预期进行(例如,我们将 Web 服务器数量增加了一倍,但响应时间仍然超过两秒),则请查看其他瓶颈。例如,您将 Web 服务器数量增加了一倍,但数据库服务器仍然很差。或者,您克隆了更多虚拟机,但由于它们位于同一物理主机上,因此您只会对服务器资源产生更高的争用。

然后,您可以使用此过程测试系统的其他部分。不要访问负载平衡器,而是尝试直接访问 Web 服务器,或使用 SQL 基准测试工具的 SQL 服务器

答案2

容量规划从测量开始,在本例中是响应时间与负载的关系。一旦您知道程序在负载下变慢的程度(这不是一个线性函数),您就可以选择一个响应时间目标,然后发现在给定负载量的情况下需要哪些资源才能达到该目标。

绩效衡量总是通过时间单位,如

  • 它们是用户关心的
  • 它们可以放大或缩小

%CPU 和 IOPS 之类的东西是系统特定的,因此只有在规划系统并在预生产中测量时才使用它们,以作为您关心的时间的“替代品”。

但是,高 CPU 或 I/O 通常表示索引不良和/或查询表述不良。使用“slowlog”来跟踪哪些查询是“最差的”。

答案3

容量规划是一件麻烦事。它既是一门科学,也是一门艺术(当然,它也算得上是一门黑暗艺术)。

最好的情况是,你做出了明智的决定命运会眷顾你,因为现实与你的假设相符。如果你的能力需求假设与现实相符,你看起来就像一个神秘的瑜伽士。不幸的是,如果你的假设超出了现实,你就会显得超支了。更不幸的是,如果你的假设低于最终的现实(或不正确),你将缺乏所需的能力,并且必须努力减轻你呻吟的基础设施的故障,这会让你看起来缺乏能力。

无压力...

不幸的是,容量规划的黑暗艺术无法合理地提炼成单个服务器故障答案;确实,这是一个值得写书的主题。

幸好,有这样一本书:”容量规划的艺术

答案4

此外,我建议与设计/构建应用程序的建筑师和工程师交谈,以尝试找出瓶颈、单点故障和许可限制。

相关内容