字节流和字符流哪个不刷新
您别无选择–底层系统(此处的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秒的延迟)。
影响力
下图显示了好人如何受到影响。 尽管“好人”的点击量没有变化,但仍然受到影响,因为其他因素导致了峰值。
请去告诉JVM您不喜欢节流
下一个是什么
您确实有3个选择(我们将在单独的文章中详细介绍以下各项)
- 自动缩放应用程序服务器,并希望新服务器能及时准备就绪以处理负载,或者;
- 在节流和控制自己的命运方面做些什么 - 如果 高流量不是创造收入的资源,而好人却是呢?
- 继续皱着眉头
翻译自: https://www.javacodegeeks.com/2015/08/dont-like-throttling.html
字节流和字符流哪个不刷新