这篇博客文章讨论了负载下的基准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 {@GET@Produces("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查询参数，该参数指定服务在完成之前应休眠的时间（以毫秒为单位）（最少10 ms）。 这可以模拟可能需要很长时间（或很短时间）才能完成的远程微服务。
为了模拟负载，我们使用了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的新（ish）G1垃圾收集器。 我们要做的就是选择一个最大的暂停时间目标（我们选择了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();}@GET@Produces("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 ，它将尝试快速发现问题并隔离发生故障的微服务。 像超时一样，断路器始终是个好主意，但是如果我们可以显着提高电路的容量，我们可能应该这样做（并且为了安全起见，仍然要安装断路器）。
现在，让我们看看异步方法的发展。
对异步方法进行基准测试
异步方法不为每个连接分配线程，而是使用少量线程来处理大量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();}@GET@Produces("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的最新版本支持servlet，JAX-RS服务器和客户端以及JDBC。 即将发布的版本（以及基准中使用的版本）将增加对Apache HTTP客户端，Dropwizard，JDBI，Retrofit以及可能的jOOQ的支持。
翻译自: https://www.javacodegeeks.com/2015/04/scalable-robust-and-standard-java-web-services-with-fibers.html
