Akka Http性能调整

时间:2016-12-23 07:50:12

标签: scala akka akka-http

我在Akka-http框架(版本:10.0)上执行负载测试,我正在使用wrk工具。 wrk命令:

wrk -t6 -c10000 -d 60s --timeout 10s --latency http://localhost:8080/hello

首次运行时没有任何阻塞调用,

object WebServer {

  implicit val system = ActorSystem("my-system")
  implicit val materializer = ActorMaterializer()
  implicit val executionContext = system.dispatcher
  def main(args: Array[String]) {


    val bindingFuture = Http().bindAndHandle(router.route, "localhost", 8080)

    println(
      s"Server online at http://localhost:8080/\nPress RETURN to stop...")
    StdIn.readLine() // let it run until user presses return
    bindingFuture
      .flatMap(_.unbind()) // trigger unbinding from the port
      .onComplete(_ => system.terminate()) // and shutdown when done
  }
}

object router {
  implicit val executionContext = WebServer.executionContext


  val route =
    path("hello") {
      get {
        complete {
        "Ok"
        }
      }
    }
}

wrk的输出:

    Running 1m test @ http://localhost:8080/hello
  6 threads and 10000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.22ms   16.41ms   2.08s    98.30%
    Req/Sec     9.86k     6.31k   25.79k    62.56%
  Latency Distribution
     50%    3.14ms
     75%    3.50ms
     90%    4.19ms
     99%   31.08ms
  3477084 requests in 1.00m, 477.50MB read
  Socket errors: connect 9751, read 344, write 0, timeout 0
Requests/sec:  57860.04
Transfer/sec:      7.95MB

现在,如果我在路线中添加未来的电话并再次运行测试。

val route =
    path("hello") {
      get {
        complete {
          Future { // Blocking code
            Thread.sleep(100)
            "OK"
          }
        }
      }
    }

wrk的输出:

Running 1m test @ http://localhost:8080/hello
  6 threads and 10000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   527.07ms  491.20ms  10.00s    88.19%
    Req/Sec    49.75     39.55   257.00     69.77%
  Latency Distribution
     50%  379.28ms
     75%  632.98ms
     90%    1.08s 
     99%    2.07s 
  13744 requests in 1.00m, 1.89MB read
  Socket errors: connect 9751, read 385, write 38, timeout 98
Requests/sec:    228.88
Transfer/sec:     32.19KB

正如您将来看到的那样,只有 13744请求正在投放

在关注Akka documentation之后,我为路由添加了一个单独的调度程序线程池,创建了 200个线程的最大值。

implicit val executionContext = WebServer.system.dispatchers.lookup("my-blocking-dispatcher")
// config of dispatcher
my-blocking-dispatcher {
  type = Dispatcher
  executor = "thread-pool-executor"
  thread-pool-executor {
    // or in Akka 2.4.2+
    fixed-pool-size = 200
  }
  throughput = 1
}

经过上述改动后,性能有所改善

Running 1m test @ http://localhost:8080/hello
  6 threads and 10000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   127.03ms   21.10ms 504.28ms   84.30%
    Req/Sec   320.89    175.58   646.00     60.01%
  Latency Distribution
     50%  122.85ms
     75%  135.16ms
     90%  147.21ms
     99%  190.03ms
  114378 requests in 1.00m, 15.71MB read
  Socket errors: connect 9751, read 284, write 0, timeout 0
Requests/sec:   1903.01
Transfer/sec:    267.61KB

my-blocking-dispatcher config 中,如果我将池大小增加到200以上,则性能相同。

现在,我应该使用哪些其他参数或配置来提高使用未来呼叫时的性能。因此该应用程序可以提供最大吞吐量。

2 个答案:

答案 0 :(得分:27)

首先是一些免责声明:我之前没有使用wrk工具,所以我可能会出错。以下是我为这个答案做出的假设:

  1. 连接数与线程数无关,即如果我指定-t4 -c10000则保持10000个连接,而不是4 * 10000。
  2. 对于每个连接,行为如下:它发送请求,完全接收响应,并立即发送下一个,等等,直到时间用完。
  3. 此外,我在与wrk相同的机器上运行服务器,我的机器似乎比你的机器弱(我只有双核CPU),所以我减少了wrk' s线程数为2,连接数为1000,以获得不错的结果。

    我使用的Akka Http版本是10.0.1,而wrk版本是4.0.2

    现在回答。让我们看一下您的阻止代码:

    Future { // Blocking code
      Thread.sleep(100)
      "OK"
    }
    

    这意味着,每个请求至少需要100毫秒。如果您有200个线程和1000个连接,则时间轴将如下所示:

    Msg: 0       200      400      600      800     1000     1200      2000
         |--------|--------|--------|--------|--------|--------|---..---|---...
    Ms:  0       100      200      300      400      500      600      1000
    

    其中Msg是已处理消息的数量,Ms是经过的时间(以毫秒为单位)。

    这给了我们每秒处理2000条消息,或者每30秒大约60000条消息,这大部分都符合测试数据:

    wrk -t2 -c1000 -d 30s --timeout 10s --latency http://localhost:8080/hello
    Running 30s test @ http://localhost:8080/hello
      2 threads and 1000 connections
      Thread Stats   Avg     Stdev     Max   +/- Stdev
        Latency   412.30ms   126.87ms 631.78ms   82.89%
        Req/Sec     0.95k    204.41     1.40k    75.73%
      Latency Distribution
         50%  455.18ms
         75%  512.93ms
         90%  517.72ms
         99%  528.19ms
    here: --> 56104 requests in 30.09s <--, 7.70MB read
      Socket errors: connect 0, read 1349, write 14, timeout 0
    Requests/sec:   1864.76
    Transfer/sec:    262.23KB
    

    很明显,这个数字(每秒2000条消息)严格受线程数限制。例如。如果我们有300个线程,我们每100毫秒处理300条消息,所以如果我们的系统可以处理这么多线程,我们每秒会有3000条消息。如果我们为每个连接提供1个线程,即池中的1000个线程,那么让我们看看我们将如何运作:

    wrk -t2 -c1000 -d 30s --timeout 10s --latency http://localhost:8080/hello
    Running 30s test @ http://localhost:8080/hello
      2 threads and 1000 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency   107.08ms   16.86ms 582.44ms   97.24%
        Req/Sec     3.80k     1.22k    5.05k    79.28%
      Latency Distribution
         50%  104.77ms
         75%  106.74ms
         90%  110.01ms
         99%  155.24ms
      223751 requests in 30.08s, 30.73MB read
      Socket errors: connect 0, read 1149, write 1, timeout 0
    Requests/sec:   7439.64
    Transfer/sec:      1.02MB
    

    正如您所看到的,现在一个请求平均花费大约100毫秒,即我们放入Thread.sleep的数量相同。看来我们不能比这快得多!现在我们几乎处于one thread per request的标准状态,这种情况多年来运作良好,直到异步IO让服务器扩展得更高。

    为了便于比较,这里是我的机器上使用默认的fork-join线程池的完全非阻塞测试结果:

    complete {
      Future {
        "OK"
      }
    }
    
    ====>
    
    wrk -t2 -c1000 -d 30s --timeout 10s --latency http://localhost:8080/hello
    Running 30s test @ http://localhost:8080/hello
      2 threads and 1000 connections
      Thread Stats   Avg      Stdev     Max   +/- Stdev
        Latency    15.50ms   14.35ms 468.11ms   93.43%
        Req/Sec    22.00k     5.99k   34.67k    72.95%
      Latency Distribution
         50%   13.16ms
         75%   18.77ms
         90%   25.72ms
         99%   66.65ms
      1289402 requests in 30.02s, 177.07MB read
      Socket errors: connect 0, read 1103, write 42, timeout 0
    Requests/sec:  42946.15
    Transfer/sec:      5.90MB
    

    总而言之,如果使用阻塞操作,每个请求需要一个线程来实现最佳吞吐量,因此请相应地配置线程池。您的系统可以处理多少线程有自然限制,您可能需要调整操作系统以获得最大线程数。为获得最佳吞吐量,请避免阻塞操作

    也不要将异步操作与非阻塞操作混淆。使用FutureThread.sleep的代码是异步但阻塞操作的完美示例。许多流行的软件在这种模式下运行(一些传统的HTTP客户端,Cassandra驱动程序,AWS Java SDK等)。要完全获得非阻塞HTTP服务器的好处,您需要一直非阻塞,而不仅仅是异步。它可能并不总是可能,但它是值得努力的。

答案 1 :(得分:0)

通过此配置,我可以在本地主机上获得x3的性能:

akka {
  actor {
    default-dispatcher {
      fork-join-executor {
        parallelism-min = 1
        parallelism-max = 64
        parallelism-factor = 1
      }
      throughput = 64
    }
  }

  http {
    host-connection-pool {
      max-connections = 10000
      max-open-requests = 4096
    }

    server {
      pipelining-limit = 1024
      max-connections = 4096
      backlog = 1024
    }
  }
}

也许这些参数的其他值会更好(如果可以,请写信给我)。

Akka Http版本10.1.12。