大家好，我与DataLine网站项目总监Alexey Pristavko保持联系。
黑色星期五是世界上最大的电子商务盛事，每年11月下旬举行。 现在是创纪录的折扣时间，商店几乎在午夜营业，并且参与该活动的站点下降，尽管流量急剧增加。
因此，以她的示例为例，我们将分析如何为严重增加网站或Web应用程序的负载做准备。
在主持下，我们将详细讨论在线商店的IT经理，开发人员和管理员如何在大型活动中生存。
什么威胁黑色星期五
就像我在上面写的那样，黑色星期五的日子给参与电子商务网站维护的每个人造成很多麻烦。
要感受一下，请考虑以下图表。 它反映了黑色星期五期间网站上的请求数量增加。
与正常的每日高峰相比，没有股票时，黑色星期五的访问量增长了100-200％，这不是极限。
如果大型网站已经拥有大量流量，那么在活动期间，规模适中的在线商店将很容易吸引到尽可能多的访问者并感到窒息。 用旧的笑话来解释一下：“业务使所有商店都不同，在线黑色星期五使每个人都变得平等。”
黑色星期五赚来的钱可以在整个明年“养活”卖方。 该企业对吸引最大数量的新客户非常感兴趣，这些新客户将返回该站点一次又一次地购买。 但是为此，他们在该站点的初次体验应该顺利进行，并确保这是IT专家的任务。
同时在现场的客户越多，对其稳定性和响应速度的要求就越高。 您肯定会注意到，您从blackfridaysales登录页面切换到该商店的网站时，其运行速度非常慢，或者根本无法运行。 我怀疑您是否正在等待下载，但几秒钟后没有离开。
我们将在下面讨论如何保护客户免受不良体验的侵害，以及如何避免网站因过载而崩溃。 但是，更多提示适用于任何预期的峰值负载。
通常，为增加流量准备站点的过程分为两个阶段：
技术阶段和
组织阶段。 在本文中，我们将讨论技术阶段，第二部分将详细介绍组织细节，该细节将在一周内发布。
网站的技术准备
一个小的免责声明：不要指望在这里找到有关如何，在何处以及如何收紧它的详细说明，以免“所有人的幸福都白费，而没有人冒犯”。 首先，每个人的站点和项目都是不同的。 其次，仅针对特定软件的特定技术建议就足够了。 包括哈布雷（Habré）。 首先，我想向读者传达使用Web项目的基本原理，并展示起点，介绍基本技术和与平台无关的细微差别。让我们从公理开始：用户不喜欢等待，因此使用时间和响应速度非常重要。 在黑色星期五，对网站的请求将比平时更多，并且您不仅可能会由于加载时间长而导致转换次数减少，而且HTTP超时也会过多（网站无法响应）。
大多数情况下，站点承受负载不是因为物理故障，而是因为某些节点上的过载导致响应时间开始超过超时。 这类似于交通拥堵，并且在一段时间内您将需要自己掌控：扩大（称重）设备，调整，切断和配置（超时），优化车辆的负载（包裹和要求）以及进行例外处理。
由于在网站性能方面有两个方面-响应速度和同时处理的请求数，我们将改善这些参数。
根据Google Analytics（分析），企业通常将响应速度表示为网站速度，将同时请求的数量表示为网站上同时出现的用户数。
在技术工作中，使用这些参数操作不是很方便。
接下来，我将为计算提出一个更合适的指标。
我们优化响应速度
在优化响应速度时，我们对两个指标感兴趣：
服务器响应速度和
页面加载时间。页面加载时间包含以下链接：
- 服务器页面生成时间；
- 从服务器到客户端的页面传输时间；
- 客户浏览器中的页面处理时间。
当一切正常进行时，页面加载时间的决定性因素不是服务器生成页面的时间和网络上交付页面的时间，而是前端的质量和浏览器中站点的速度。 由于后者完全在用户方面，因此您不必担心黑色星期五的刹车。 但是，由于您的Internet通道或外部组件（关联计数器，在线聊天，CRM插件等）的传递过大，可能会出现问题。
怎么处理呢？ 以下是一些工作提示：
- 检查互联网通道的负载。 计算估计的增长。 如有疑问，请扩大渠道。 一些提供商除了持续不断地进行昂贵的扩展外，还可能为您提供高峰期的临时扩展（便宜得多），甚至允许您短暂超过最大速度。
- 使用CDN？ 联系技术支持并警告计划的流量增长。 他们还在为高峰期做准备，您的预测将派上用场。 如果CDN承诺一切都会好起来，但是尽管一切都会“躺下”，则通信的存在将有助于提出索赔要求。
- 事先，编写脚本以在出现问题时临时禁用外部组件。 使方案与业务保持一致。 与所使用的服务的技术支持进行通信并不是多余的，无论如何，否则通常不可能以某种方式影响它们。
- 在许多站点上，使用应用程序服务器呈现静态。 在高负载下，对静态的请求数量增加了很多倍，并且它们开始与应用程序本身竞争资源。 确保配置直接从Nginx返回的静态变量。 首先，它将对此做得更好，其次，对于Apache，Tomcat或Jetty线程，将有更多有用的工作。
提高响应速度
响应速度本身的优化是指站点性能的整体提高。 从理论上讲，它有助于减少应用程序执行的工作量，并因此提高了伸缩性-因为如果每个请求变得“便宜”，则可以使用相同的资源处理更多请求。
但实际上，优化响应速度需要大量的独立工作。 不可能一次优化所有内容，但在此过程中破坏某些内容很容易。
提示：系统思考。 假设代码性能得到提高，并且应用程序已开始进行更多同时数据库查询。 但这就是问题所在：数据库性能不允许处理如此多的请求，整个站点只会变得更糟，并且在活动之前花费了宝贵的时间。
因此，最好将注意力集中在扩展性和可伸缩性上，并与准备黑色星期五分开进行总体优化，以免因时间紧迫而混乱。 请记住，现在我们的任务是确保在负载高峰时，该站点的运行不会比外部运行的差。
页面生成速度仅与另一个指标（传入负载量）结合在一起才对我们感兴趣。
请注意：对于网站，仅由用户创建的并发请求数很重要，而与网站上的在线用户数无关。 而且要以可接受的精度计算
每秒的请求 数与访问者的
数量相当困难（我在上面已经写过）。 最好向企业询问其他指标-每小时的浏览量和服务器时间。
结果，我们得到了一个可以理解的目标：确保时间X的页面生成和每秒的请求数Y。手头有特定的数字量度，很容易评估准备水平和当前结果。
以下是一般技术培训计划：
- 找出当前指标（对站点当前版本进行负载测试）；
- 了解确切缺少的东西以及订购多少资源；
- 添加资源；
- 重复压力测试，看看是否有帮助。
看起来太简单了？ 没错，每一点都充满了许多惊喜。
通常，添加资源可以部分改善情况，但不能节省全部费用。 或者在测试环境中，该站点就像时钟一样工作，并在产品上-再次刹车。
接下来，我将向您展示如何识别潜在问题并修复弱点。 让我们从如何进行压力测试并获得真实结果开始。
我们正确进行负载测试
在哪里测试？
通常，压力测试是在生产系统上进行的。 这可能有利于整体控制局势，但不利于迭代解决特定问题。 请记住，通常在消除新发现的问题之后，可能会出现新的问题。 银弹很少击中目标。
负载测试失败会给站点用户带来不便，甚至“破坏”一段时间。 最好将专用区域用作实验兔。
它必须满足以下要求：
- 专用区域应完全独立且与生产区域隔离；
- 理想情况下，专用区域应与产品尺寸保持一致。 大型模型也适用，但是会降低测试的质量和重要性。 如果资源上的负载呈非线性增长（通常会发生这种情况），则您的模型将不会显示在满负载下资源会提前耗尽；
- 最好使用与产品完全相同（但不相同！）的设备进行测试。 否则，即使观察到资源的定量值，也无法提供质量。 在关键时刻，它可能会开玩笑。 如果无法做到这一点，请在您的负载下测试设备的性能，并确定调整系数。
现在让我们讨论一下生成测试负载的方法。 我将介绍一些基本技术，每种技术都有其优缺点。
如何产生负载？
1.根据日志请求进行测试可以模拟战斗服务器日志中的流量。 这种方法的明显优势是您不必费心分析，统计建模和综合流量概况。
但是您仍然必须从无法完成或不需要的请求中清除日志。
例如，您不需要在生产性产品上“购买”商品，这会导致数据库的产品内容出现问题。
在请求之间重现现实的延迟将很困难。
模拟用户会话也非常困难，这种方法非常接近基于匹配的测试。
2.使用Yandex.Tank和Phantom与Phantom结合使用的储罐是用于基于击打的测试的非常方便且流行的工具。 它具有周到的界面，可让您管理负载。 要开始从坦克脱壳，您必须准备“弹药筒”-包含生成器要求的特殊文件。
但是，尽管有很多便利，但Tank仍然有一个主要缺点：它不知道如何使用用户会话。
您可能会忘记授权，关于cookie的全部工作以及各种延迟。 坦克只能“啄”来自单个地址的请求。
如果满足以下条件，它将适合您：
- 授权和未授权用户的服务器响应时间没有差异，或者可以忽略不计；
- 显式测试没有HTTP会话的API；
- 这种方法通常与您网站的逻辑一致（通常不适合在线商店）。
3.使用Apache JMeter这是最灵活的工具，可让您详细模拟用户会话。 因此，在它的帮助下，您仍然可以回答业务问题“该站点可以承受多少用户？” 此外，JMeter可以与Yandex.Tank协同工作。
它的主要缺点是资源消耗和准备测试的复杂性。
直接关于JMeter的主要建议：尽量避免用力分析页面主体，最好使用预先准备的数据集来重现会话逻辑。 原则上，最好将JMeter所做的工作减至最少。 像Tank一样，可以将预先生成的“墨盒”连接到它。 在这里，他们需要考虑一种类型中特定页面的分布，请求的可变性以及所有爵士。
在JMeter本身中，需要对用户行为模型进行编程。 如果任务不仅要测试服务器部分，还要测试静态内容的返回，请使用Phantom单独运行此测试，必要时与JMeter测试同时进行。 这将有助于显着减少负载生成器的资源消耗并提高测试的可重复性。
压力测试建议良好的负载测试基于有效的流量分析以及高质量的统计模型和仿真配置文件的准备。
突出显示5-7个主要的页面类型（不要忘记有关股票的登陆页面），计算在页面之间分配的总访问量的百分比。 请记住，每页可能会有几个动态内容请求。 对于您来说，页面是此类请求的整个组。 分析用户在每种类型的页面上花费的时间：平均值，平均值最小值，平均值最大值。
如果页面建立在多个请求上，请考虑它们之间的延迟。 查看用户通常每个会话访问多少页面，该数量的分布情况。 按页面类型突出显示最常见的用户路径的5-10。
使用获得的数据，以某种方式构造方案，以极其精确地重现所有描述的统计参数。 不要忘记方案的可变性，它们的点击次数和构成都应有所不同。
在每种页面类型中，突出显示各个地址。 越多越好，但是已经有成千上万个最受欢迎的地址引起了人们的注意。 您可以根据需要通过将每个地址添加到列表中多次来从中准备查询列表。
如果页面太多，则根据流量百分比将它们分成几组。
配置文件仅对JMeter起作用，但是通过构建查询列表，您可以装备“坦克”墨盒。
再说一遍：在用户仿真模式下使用JMeter时，请不要忘记请求之间的延迟。 如果不添加它们，则生成的负载将比计划高很多倍！
试运行后，请确保检查Web服务器日志以查看模拟流量是否有效。
特技飞行人员将提前准备脚本，以使站点数据库达到您所需的状态。 通常，以上述方式准备的数据仅适用于收集了商品信息的数据库状态。 每次重新加载SQL转储的时间可能过长。 另外，非常需要学习如何使用测试区域中的脚本来管理流动库存。 通常，它们对于系统的运行很重要，您需要了解
什么设置以及
如何精确测试工作库存。
准备好了吗 太好了，继续前进！
我们在测试中使用监控
因此，我们进行了胜任的测试并获得了结果。 如果一切都很好，并且您的站点正在处理高负载，那么黑色星期五对您来说并不可怕。 但是，如果我们不考虑
可悲的现实情况，本文将是不完整的。
想象一下，一个站点可以承受一个可接受的速度……很好，即使该业务只想获得五分之一的速度。 真的有必要紧急呼叫托管服务商并订购五倍的容量吗？
原则上，主持人会喜欢这种方法。 您甚至可以获得金牌客户的身份。
但是在轻率采取行动之前，让我们尝试找出到底出了什么问题。
您的海上救生浮标可能是一个监视系统。
因此，我们退后一步并在测试之前安装尽可能多的示例。 理想情况下，应监控所有可用资源。
以下是帮助您入门的列表：
- CPU负载（CPU使用率，CPU负载）；
- RAM加载；
- 磁盘加载（IOPS，延迟）；
- 网络连接数（时间等待，Fin等待，关闭等待，已建立）；
- 打开的插座数；
- 用户进程数；
- 打开的文件数；
- 网络流量（以兆位和数据包为单位，加上错误和丢弃）。
并且：
- 查询，响应以及与数据库和其他组件的连接数；
- 组件响应速度（数据库，搜索服务器，缓存等）；
- 所有可用日志中的错误。
对于所有这些参数，您应该知道可用的限制。这将使我们能够准确了解压力测试过程中“瓶颈”的形成位置。请记住，这些“资源”大多数都是可配置的；有些通常由设置来管理。也许只需要进行少量的少量修改就可以改善性能。需要在某个地方而不是数量上但在质上进行更改：例如，用SSD替换HDD。在我的上一篇文章中 可以找到有关优化和扩展Web应用程序以及提高容错能力的一些技巧。另外，在订购资源之前，我建议您将系统上的负载增长图与其负载图进行比较。不一定会有线性关系。另一个提示：请记住，我们说过用户不知道要等待多长时间？如果您和企业已同意页面生成时间（有条件地）超过2秒是绝对不能接受的，并且可以认为该用户已离开，请记下超时（例如0.5秒）以连接到后端并花费1.5秒答案。如果下载时间较长，则可以为用户提供有关错误的页面或空白，例如“噢，再试一次”。在后端，您可以在1秒内设置数据库的最大期望值，依此类推。这样的机制将不允许对不再有时间的组件施加负载。因此，您将减少系统的总体负载并保护其免受长期过载和故障的影响。最终，提供优质工作的策略（而不是不惜一切代价给出答案的策略）大大减少了遇到问题的用户数量。我们订购设备
一旦发现需要扩展的区域，就可以订购设备。如果您订购大量“物理”硬件，请记住交货时间。他们大约需要2-3个月，再加上一个月的时间用于测试，安装工作和调试。在云中订购大量资源时，请记住：您不是唯一要在那里体验“黑色星期五”的人。建议主机几个月，以便您拥有足够的设备。当然，云是有弹性的，但是当它们全部落下来时，您可能会感到尴尬。订购云中的处理器功能将具有更大的远见。在竞选期间，许多提供商将增加物理资源的负担。它们很可能不会超出SLA中规定的限制，但是硬件的工作速度可能比“安静”期间的测试慢一些。不要忘记信息安全工具。很少有人将它们不仅保留在生产环境中，而且还保留在测试区域中。他们也可能缺乏资源。不要忘记，即使是对系统运行的任何最有用的干预也可能破坏其稳定性。您无法将添加资源的时间推迟到最后一天，至少要等两周，以便有时间检查所有内容并抓紧最后的卷轴。升级后，您需要重复测试并确保该站点能够承受负载。首先，增加资源的过程可能是反复的（可能会出现新的需求），其次，人为因素也没有被消除。即使是经验丰富的专家也可能在安装过程中承认门框或进行不正确的计算。也许就这些。我们检查了准备用于大量流量的Web应用程序的最重要方面，流行的负载测试方法以及在此阶段识别瓶颈的方法。如果您有任何疑问，我邀请他们不仅在评论中提问，而且在我的研讨会“电子商务的黑色星期五”中亲自提问。《生存的秘密》将于8月16日在莫斯科举行。您可以在此处注册研讨会。