Play2.x 性能调优配置

最新推荐文章于 2019-02-13 22:09:13 发布

weixin_34221073

最新推荐文章于 2019-02-13 22:09:13 发布

阅读量251

点赞数

文章标签：数据库 json

原文链接：https://my.oschina.net/moks/blog/478536

版权

为什么80%的码农都做不了架构师？>>>

转载请注明出处，保持署名作者：joymufeng

1. 为什么要调优？

1.1 实验：一个简单的示例

Play Framework2.1的基本设计思想是能够快速处理大量耗时较少的请求，比较耗时的请求采用异步方式完成。为了很好地说明这一点，让我们来看一个例子，编写控制器代码如下：

public static AtomicInteger count = new AtomicInteger(0);
public static Result test(Long id) {
    if(id!=0){
        try {
            System.out.println("sleeping...:"+count.addAndGet(1));
            Thread.currentThread().sleep(1000000);
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }else{
        System.out.println("no sleep");
    }
    return ok("good.");
}

在conf/routes文件中添加如下路由：

1	`GET /:id controllers.Application.test(id:Long)`

执行play run启动项目，下面我们打开浏览器进行测试。测试地址如下：

1	`http:` `//localhost:9000/1 - http://localhost:9000/9`

需要注意的是，所有的请求需要在浏览器的一个窗口中完成，具体原因请见下面的【说明】。控制台消息如下：

可以看出，在我们发送第9次请求时，服务器报了error，错误原因是“AskTimeoutException”，请求actor超时。

【说明】

在上面的测试中，要求所有请求需要在一个浏览器窗口中完成，主要是因为各个版本的浏览器针对同一个域，有最大连接数限制，例如IE6、IE8和Chrome21的连接数如下：

Chrome21的最大连接数： 6

IE8的最大连接数： 6

IE6的最大连接数： 2

这意味在访问下一个页面时，需要将之前的页面关掉，否则在Chrome21中，当打开第7个选项卡访问页面时，前面6个选项卡Chrome提示“正在等待响应”，而第7个选项卡Chrome提示“正在发送请求”，这是因为前面的6个选项卡已经占满了6个连接，第7个选项卡只能等待前面的连接释放。

1.2 小结

从上面的实验结果，可以观察到，默认情况下Play2.1只能同时处理8个耗时请求，在这个8个耗时请求未结束之前，第9个请求将会在默认的等待时间（1秒）结束后，报”500服务器内部错误“。

一、Akka actor配置

Play2.x的默认配置已经能够满足大部分小型应用的需要了。但在面对数据/计算密集型的应用，或是高并发的应用，默认的配置就显的力不从心了。本文主要从两方面来提高Play2.x的性能，一方面是提高请求处理的并发数；另一方面，仅仅提高处理请求的并发数，在高并发情况下（如压力测试）仍然会处理“AskTimeoutException”，所以要提高这个等待时间。

在《Play Framework2.1源码分析 - 架构设计及线程策略分析》介绍了，在Play2.x中，实际处理请求的执行环境是AKKA的actors，而执行actors的线程资源是由跟actor相关联的 dispatcher管理的。在Play2.1中，所有的AKKA actors都使用默认的default-dispatcher，其默认配置如下：

play { akka {
actor {
    retrieveBodyParserTimeout = 1 second
    default-dispatcher = {
      fork-join-executor {
        parallelism-min = 8
        parallelism-factor = 1.0
        parallelism-max = 24
      }
    }
}
}
}

其中retrieveBodyParserTimeout参数值的是，如果没有可用的actor处理请求，则默认等待1s，如果还没有则报500错误。接下来的三个参数parallelism-min、parallelism-factor和parallelism-max，就是具体的线程池配置了。parallelism-min和parallelism-max参数指明最小和最大线程数分别是8和24，parallelism-factor是线程池大小的计算因子。看到min和max，相信很多人第一时间会联想到数据库连接池的配置，需要注意的是，这里的min和max的含义和数据库连接池的含义完全不同，只是作为最终计算结果的一个参考比较。下面说明一下线程池大小计算的具体过程：

- 首先计算parallelism-factor*processors, 其中processors为CPU的总核数，例如对于i5处理器，processors大小为4

- 如果parallelism-factor*processors计算结果小于parallelism-min，则线程池大小为parallelism-min

- 如果parallelism-factor*processors计算结果大于parallelism-max，则线程池大小为parallelism-max

我们看到，parallelism-min和parallelism-max参数只是起到校正parallelism-factor*processors计算结果的作用。

好了，通过上面的介绍，我想你应该知道怎么做了，这里给一个示例，把下面这部分配置追加到con/application.conf文件的尾部。下面的参数书写方式和自动生成的不太一样，不用担心，Play支持多种书写方式，例如点式“db.default.user=sa”和下面这种类似JSON的方式，具体请参考官方文档，

play {
akka {
   actor {
     retrieveBodyParserTimeout = 5 second
     default -dispatcher = {
       fork-join-executor {
         parallelism-min = 10
         parallelism-factor = 100
         parallelism-max = 100
       }
     }
   }
}

}

以上内容摘自：http://my.oschina.net/joymufeng/blog/107874

性能测试对比：

默认配置（local:win8-8Core-8G）：