您别无选择–基础系统（此处的JVM将为您完成此选择）。
我仍然记得2013年夏天，当时我正在运行一个项目，整个应用程序中只有1个URL使服务器瘫痪。 问题很简单-机器人决定以很高的速率索引我们的网站，并且该机器人正在创建数百万个URL组合，这些组合绕过了我所有的缓存层，并且都击中了我的应用程序服务器。 好吧，我们在应用程序中的缓存率非常高（大约95％），并且应用程序服务器层并不是为高负载而设计的（这是Adobe AEM 5.6，执行搜索和制作页面的逻辑在计算上非常繁琐）。 那年早些时候，我们想处理Dog-Pile效应的案例，并且我们谈到要进行某种限制。 在对话开始时，每个人都对节制相同的想法不满意（2个人除外）。
在2012年秋天， Ravi Pal建议采取适当的错误处理措施，使系统不仅应该掉在头上，而且应优雅地降级。 当我们在2013年遇到这个问题时，我才意识到他建议的严重性。
现在，我正在另一个平台上工作，当我提出节流的想法时，它又一次被皱了皱眉。 一个人在一次会议上实际上嘲笑我。 另一个人建议我们要通过“自动缩放”处理场景，而不是限制场景。 我们在AWS Cloud上拥有基础架构，但我不是专家，但是专家告诉我，服务器可以在大约10分钟内原样复制（我们将 证明 对此进行基准测试）。
我是一位雄心勃勃的建筑师，尽管我控制了进入我网站的流量。 我不再生活在那种幻想中。
这可能是一系列的帖子，但是今天在这里我开始向您展示您没有选择的余地，无论您是否喜欢它，系统都会为您限制流量。
基准概述
- 使用Spring Boot构建的简单Web应用程序
- 一个Spring MVC REST控制器 ，它将接受一些HTTP请求并在诱发的延迟后发送回OK响应
- jMeter模拟负载
- 一个自定义插件 （向这些家伙大喊大叫的插件）可生成逐步加载并捕获自定义增强图
- 托管网站的Tomcat 8.x –使用Spring Boot在内存中启动。 未完成自定义
第一组–好人
测试计划
该线程组将模拟对我们的应用程序服务器的一致请求流。 一个典型的情况经常发生。
服务器性能
如预期的那样？ 是。
如下图所示，该图表显示应用程序服务器的行为正常。 15分钟内的所有请求都与“单用户模型”（也就是1秒请求响应时间）一致。
第二组-突发的高流量
测试计划
该测试计划是一种分步实施的方法，它试图模拟一种情况，即广告活动将在短时间内开始到达某个页面（或一组页面）。 在我们的网站向全世界开放的行业中，我们经常看到这种用例。
这个线程组不是OOTB，我下载了一个插件
服务器性能
那么，我们期望发生什么呢？ 根据我的服务器有多少果汁（线程，cpu循环等），我的服务器可能会或可能无法处理请求。 鉴于我正在本地笔记本电脑上运行所有程序，如果我的本地机器可以处理600个线程，那将很有趣。
而且我们发现我的笔记本电脑无法真正处理600线程。 那么，tomcat是做什么的呢？
它节流
好人变化的表现
测试计划
我运行第一个测试计划，并遵循高流量计划（引入30秒的延迟）。
影响力
下图显示了好人如何受到影响。 尽管The Good One的访问量没有变化，但仍然受到影响，因为其他因素导致了峰值。
请告诉JVM您不喜欢节流
下一个是什么
您实际上有3个选择（我们将在单独的文章中详细介绍以下各项）
- 自动缩放应用程序服务器，并希望新服务器能及时准备就绪以处理负载，或者
- 在节流和控制自己的命运方面做些什么 - 如果 高流量不是好收入来源，好人却是收入来源呢？
- 继续皱着眉头
翻译自: https://www.javacodegeeks.com/2015/08/dont-like-throttling.html
