西安企业网站建设模板,国外网站网页设计,ciid中国室内设计大奖赛,北京市市场监督管理网上服务平台博科光纤交换机java这篇博客文章讨论了负载下的基准Web服务性能。 要了解有关Web服务性能理论的更多信息#xff0c;请阅读利特尔定律#xff0c;可伸缩性和容错 。 使用阻塞和异步IO对Web服务进行基准测试 Web应用程序#xff08;或Web服务#xff09;如何在负载下#… 博科光纤交换机java 这篇博客文章讨论了负载下的基准Web服务性能。 要了解有关Web服务性能理论的更多信息请阅读利特尔定律可伸缩性和容错 。 使用阻塞和异步IO对Web服务进行基准测试 Web应用程序或Web服务如何在负载下面对各种故障时以及在两种情况的组合下表现如何这是我们代码最重要的特性-当然是正确的。 由于Web服务通常执行非常常见的操作-询问缓存数据库或其他Web服务以收集数据将其组合并返回给调用方-因此这种行为主要取决于Web框架/服务器及其架构的选择。 在先前的博客文章中 我们讨论了利特尔定律并将其应用于分析Web服务器采用的不同体系结构方法的理论限制。 这篇文章对该文章的补充重新讨论了同一主题只是这次我们将在实践中衡量绩效。 Web框架我用这个术语来指代任何通过运行用户代码来响应HTTP请求的软件环境无论是被称为框架应用程序服务器Web容器还是语言的标准库的一部分都选择以下一种两种架构。 首先是分配一个OS线程该线程将运行我们的所有代码直到请求完成。 这是标准Java servlet Ruby PHP和其他环境所采用的方法。 这些服务器中的某些服务器在单个线程中运行所有用户代码因此它们一次只能处理一个请求。 其他人在不同的并发线程上运行并发请求。 这种称为“每个请求线程”的方法需要非常简单的代码。 另一种方法是对一个或多个OS线程尽可能使用比并发请求数更少的OS线程使用异步IO并尽可能多地将请求处理代码调度到多个并发请求。 这是Node.js Java 异步servlet和JVM框架如Vert.x和Play采用的方法 。 据推测这种方法的优点是这正是我们要衡量的更好的可伸缩性和鲁棒性面对使用率高峰失败等但是为此类异步服务器编写代码比为线程编写代码更复杂。每个请求的。 代码的复杂程度取决于使用各种“回调地狱缓解”技术例如promise和/或其他通常涉及monad的功能编程方法的使用。 其他环境则试图将两种方法的优点结合起来。 在幕后他们使用异步IO但是他们没有让程序员使用回调或monad而是为程序员提供了光纤 又称轻量级线程或用户级线程这些光纤消耗很少的RAM并且阻塞开销可以忽略不计。 这样这些环境在保持同步阻塞代码的简单性和熟悉性的同时具有与异步方法相同的可伸缩性/性能/鲁棒性优点。 这样的环境包括Erlang Go和Quasar 将纤维添加到JVM。 基准测试 完整的基准测试项目可以在这里找到。 为了测试两种方法的相对性能我们将使用一个简单的Web服务该Web服务是使用JAX-RS API用Java编写的。 测试代码将模拟微服务的现代通用体系结构但结果绝不限于使用微服务。 在微服务架构中客户端Web浏览器手机机顶盒将请求发送到单个HTTP端点。 然后该请求由服务器分解成几个通常是很多其他子请求这些子请求被发送到各种内部HTTP服务每个子服务负责提供一种类型的数据或执行一种操作例如一个微服务可负责返回用户个人资料另一个微服务负责返回其朋友圈。 我们将对单个主服务进行基准测试该主服务向另一个或两个其他微服务发出调用并检查当微服务正常运行或发生故障时主服务的行为。 将通过安装在http://ourserver:8080/internal/foo的此简单服务来模拟微服务 Singleton
Path(/foo)
public class SimulatedMicroservice {GETProduces(text/plain)public String get(QueryParam(sleep) Integer sleep) throws IOException, SuspendExecution, InterruptedException {if (sleep null || sleep 0)sleep 10;Strand.sleep(sleep); // -- Why we use Strand.sleep rather than Thread.sleep will be made clear laterreturn slept for sleep : new Date().getTime();}
} 它所做的就是使用一个sleep查询参数该参数指定服务在完成之前应Hibernate的时间以毫秒为单位至少10毫秒。 这可以模拟可能需要很长时间或很短时间才能完成的远程微服务。 为了模拟负载我们使用了Photon Photon是一种非常简单的负载生成工具使用Quasar光纤以相对较少的协调遗漏的方式发出大量并发请求并测量其延迟每个请求都是由新生成的请求发送的纤维然后依次以恒定速率生成纤维。 我们在三种不同的嵌入式Java Web服务器上测试了该服务 Jetty Tomcat 嵌入式和Undertow 为JBoss Wildfly应用程序服务器提供动力的Web服务器。 现在由于所有三个服务器均符合Java标准因此我们为所有三个服务器重用了相同的服务代码。 不幸的是没有用于以编程方式配置Web服务器的标准API因此基准测试项目中的大多数代码都简单地抽象出了三台服务器的不同配置API位于JettyServer TomcatServer和UndertowServer类中。 Main类仅解析命令行参数配置嵌入式服务器并将Jersey设置为JAX-RS容器。 我们已经在c3.8xlarge EC2实例上运行了Load Generator和服务器分别运行了Ubunto Server 14.04 64位和JDK8。如果您想自己使用基准测试请按照此处的说明进行操作。 此处显示的结果是在Jetty上进行测试时获得的结果。 Tomcat对普通阻止代码的响应类似但是使用光纤时其响应性比Jetty差这需要进一步研究。 Undertow的行为与之相反使用光纤时其性能与Jetty相似但是当线程阻塞代码面临高负载时崩溃很快。 配置操作系统 因为我们将在高负载下测试我们的服务所以需要一些配置才能在操作系统级别上支持它。 我们的/etc/sysctl.conf将包含 net.ipv4.tcp_tw_recycle 1
net.ipv4.tcp_tw_reuse 1
net.ipv4.tcp_fin_timeout 1
net.ipv4.tcp_timestamps 1
net.ipv4.tcp_syncookies 0
net.ipv4.ip_local_port_range 1024 65535 并因此被加载 sudo sysctl -p /etc/sysctl.conf /etc/security/limits.conf将包含 * hard nofile 200000
* soft nofile 200000配置垃圾收集 大多数Java垃圾收集器都是基于生成假设的 该假设假设大多数对象的寿命都非常短。 但是当我们开始使用模拟的失败的微服务测试系统时它将生成持续数秒的开放连接然后才断开。 这种“中等寿命”即也不短但也不能太长是最糟糕的一种垃圾。 看到默认的GC导致了令人无法接受的暂停并且不想浪费太多时间来微调GC之后我们选择尝试使用HotSpot的新ishG1垃圾收集器。 我们要做的就是选择一个最大暂停时间目标我们选择了200ms。 G1表现出色1因此我们没有花更多时间调整收集器。 可能是因为对象是按组分配的这些组都在同一年龄段死亡。 这种模式可能正好发挥了G1的优势。 基准同步方法 这是我们的待测服务代码从同步方法开始该代码安装在/api/service 。 完整的类其中还包括HTTP客户端的配置可以在此处找到 Singleton
Path(/service)
public class Service extends HttpServlet {private final CloseableHttpClient httpClient;private static final BasicResponseHandler basicResponseHandler new BasicResponseHandler();public Service() {httpClient HttpClientBuilder.create()... // configure.build();}GETProduces(text/plain)public String get(QueryParam(sleep) int sleep) throws IOException {// simulate a call to a service that always completes in 10 ms - service AString res1 httpClient.execute(new HttpGet(Main.SERVICE_URL 10), basicResponseHandler);// simulate a call to a service that might fail and cause a delay - service BString res2 sleep 0 ? httpClient.execute(new HttpGet(Main.SERVICE_URL sleep), basicResponseHandler) : skipped;return call response res1: res1 res2: res2;}
} 然后我们的服务会调用一个或两个其他微服务我们可以将它们命名为A和B当然两者都是由SimulatedMicroservice 。 虽然服务A总是需要10毫秒才能完成但是可以模拟服务B以显示变化的延迟。 假设服务B正常运行并在工作10毫秒后返回其结果。 这是我们的服务随时间推移每秒响应1000个请求的方式服务器使用2000个线程池。 红线是同时需要两种微服务的请求的延迟绿线是仅触发对微服务A的调用的请求的延迟 我们甚至可以将速率提高到3000Hz 超过3000Hz服务器会遇到严重困难。 现在我们假设在某个时刻服务B发生故障导致服务B以大大增加的延迟进行响应。 比方说5000毫秒 如果每秒我们在服务器上触发300个触发服务A和B的请求以及另外10个仅触发A这是控制组的请求则该服务将按应有的方式执行触发B的那些请求会增加延迟但是绕过它的人不受影响。 但是如果我们随后将请求速率提高到400Hz则会发生不好的情况 这里发生了什么 当服务B失败时触发主服务的对主服务的请求将长时间阻塞它们中的每一个都持有一个线程直到请求完成该线程才能返回到服务器的线程池。 线程开始堆积直到它们耗尽服务器的线程池为止此时没有请求-甚至没有尝试使用失败的服务的请求-都无法通过服务器实质上崩溃了。 这被称为级联故障 。 单个失败的微服务可以关闭整个应用程序。 我们怎样做才能减轻这种故障 我们可以尝试进一步增加最大线程池大小但最大限制为相当低。 OS线程给系统带来了两种负担第一它们的堆栈消耗相对大量的RAM第二它们的堆栈占用大量RAM。 使用该RAM来存储数据缓存的响应式应用程序要好得多。 其次将多个线程调度到相对较少的CPU内核上会增加不可忽略的开销。 如果服务器仅执行很少的CPU密集型计算通常是这种情况服务器通常只是从其他来源收集数据则调度开销可能会变得很大。 当我们将线程池大小增加到5000时服务器性能会更好。 在500Hz的频率下它仍然运行良好 在700 Hz时它摇摇欲坠 …并在我们增加费率时崩溃。 但是一旦我们将线程池大小增加到6000其他线程便无济于事。 这是在1100Hz下具有6000个线程的服务器 这里有7000个线程处理相同的负载 我们可以尝试在微服务调用上设置超时。 超时始终是一个好主意但是选择什么超时值 太低了可能会使我们的应用程序无法使用。 太高我们还没有真正解决问题。 我们还可以安装一个断路器例如Netfilx的Hystrix 它将试图Swift发现问题并隔离发生故障的微服务。 像超时一样断路器始终是一个好主意但是如果我们可以显着提高电路的容量我们可能应该这样做并且为了安全起见仍然要安装断路器。 现在让我们看看异步方法的发展。 对异步方法进行基准测试 异步方法不为每个连接分配线程而是使用少量线程来处理大量IO事件。 Servlet标准现在除了阻塞API之外还支持异步API但是由于没有人喜欢回调特别是在具有共享可变状态的多线程环境中因此很少有人使用它。 Play框架还具有异步API为了减轻与异步代码始终相关的某些痛苦Play用功能性编程的monadic组合替换了简单的回调。 Play API不仅是非标准的对于Java开发人员来说也感觉很陌生。 这也无助于减少与无法避免竞争条件的环境中运行异步代码相关的问题。 简而言之异步代码是一团糟。 但是我们仍然可以使用光纤测试这种方法的行为同时保持我们的代码美观简单和阻塞。 我们仍将使用异步IO但丑陋将对我们完全隐藏。 对 Comsat是一个开源项目将标准或流行的Web相关API与Quasar光纤集成在一起。 这是我们的服务现在利用Comsat 此处为全班制 Singleton
Path(/service)
public class Service extends HttpServlet {private final CloseableHttpClient httpClient;private static final BasicResponseHandler basicResponseHandler new BasicResponseHandler();public Service() {httpClient FiberHttpClientBuilder.create() // ---------- FIBER....build();}GETProduces(text/plain)Suspendable // ------------- FIBERpublic String get(QueryParam(sleep) int sleep) throws IOException {// simulate a call to a service that always completes in 10 ms - service AString res1 httpClient.execute(new HttpGet(Main.SERVICE_URL 10), basicResponseHandler);// simulate a call to a service that might fail and cause a delay - service BString res2 sleep 0 ? httpClient.execute(new HttpGet(Main.SERVICE_URL sleep), basicResponseHandler) : skipped;return call response res1: res1 res2: res2;}
} 该代码与我们的线程阻塞服务相同除了几行用箭头标记和Main类中的一行。 当B正确执行时一切都很好当服务器处理前几个请求时您会在控制台上看到一些警告提示光纤占用了太多的CPU时间。没关系。这只是执行的初始化代码 事不宜迟以下是我们的光纤服务使用40个OS线程这是Jetty的最小线程池大小频率为3000Hz 在5000Hz时 在6000Hz时需要一些时间才能完全预热但随后会收敛 现在让我们踢出问题的微服务即我们亲爱的服务B使其经历5秒的延迟。 这是我们的服务器频率为1000Hz 在2000Hz时 使用错误的服务B响应请求时除了偶尔出现峰值外航行仍然平稳但是仅撞到A的人什么也没有。 在4000Hz时它开始显示出一些明显的但不是灾难性的抖动 每秒需要处理5000个请求在失败条件下以使服务器无响应。 糟糕的是服务B可能会导致20秒的延迟但我们的服务器仍然可以每秒处理1500次触发失败服务的请求而那些未达到故障服务的请求甚至都不会注意到 那么这是怎么回事 当服务B开始显示很高的延迟时为调用B的请求服务的光纤会堆积一段时间但是由于我们可以拥有这么多的光纤并且由于它们的开销如此之低系统很快就达到了一个新的稳态-成千上万的阻塞光纤但这完全可以 进一步扩大我们的能力 因为我们的Web服务向微服务发出传出请求并且因为我们现在可以服务很多并发请求所以我们的服务最终可能会遇到另一个操作系统限制。 每个传出的TCP套接字都捕获一个临时端口 。 我们已经将net.ipv4.ip_local_port_range设置为1024 65535 总共65535 – 1024 64511传出连接但是我们的服务可以处理更多内容。 不幸的是我们不能再提高此限制但是由于此限制是针对每个网络接口的因此我们可以定义虚拟接口 并让传出请求随机或基于某种逻辑选择一个接口。 结论 光纤使用户能够享受异步IO同时保持简单和标准的代码。 因此我们通过异步IO获得的好处不是减少延迟我们尚未进行基准测试但是没有理由相信它比纯线程阻塞IO更好但是容量显着增加。 系统的稳定状态支持更高的负载。 异步IO可以更好地利用硬件资源。 当然这种方法也有缺点。 其中最主要的实际上我认为这是唯一的是库集成。 我们在光纤上调用的每个阻塞API都必须专门支持光纤。 顺便说一下这并不是仅轻量级线程方法所独有的要使用异步方法所有使用的IO库也必须是异步的。 实际上如果库具有异步API则可以轻松地将其转换为光纤阻塞的API。 Comsat项目是一组将标准或流行的IO API与Quasar光纤集成在一起的模块。 Comsat的最新版本支持servletJAX-RS服务器和客户端以及JDBC。 即将发布的版本以及基准测试中使用的版本将增加对Apache HTTP客户端DropwizardJDBIRetrofit以及可能的jOOQ的支持。 翻译自: https://www.javacodegeeks.com/2015/04/scalable-robust-and-standard-java-web-services-with-fibers.html博科光纤交换机java
