PlayFramework 2.1 技巧

Stella981
• 阅读 552

转载请注明出处,保持署名 作者: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文件中添加如下路由:

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

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

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

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

PlayFramework 2.1 技巧

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

PlayFramework 2.1 技巧

【说明】

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

Chrome21的最大连接数:6
IE8的最大连接数:6
IE6的最大连接数:2

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

PlayFramework 2.1 技巧

1.2 小结

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

2. Play2.1性能调优

    需要说明的是,Play2.1的默认配置已经能够满足大部分小型应用的需要了。但在面对数据/计算密集型的应用,或是高并发的应用,默认的配置就显的力不从心了。本文主要从两方面来提高Play2.1的性能,一方面是提高请求处理的并发数;另一方面,仅仅提高处理请求的并发数,在高并发情况下(如压力测试)仍然会处理“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
      }
    }
  }
 }
}
点赞
收藏
评论区
推荐文章
待兔 待兔
4个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
Wesley13 Wesley13
3年前
HTTP 1.1与HTTP 1.0的区别
HTTP1.1与HTTP1.0的比较一个WEB站点每天可能要接收到上百万的用户请求,为了提高系统的效率,HTTP1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。但是,这也造成了一些性能上的缺陷,例如,一个包含有
Wesley13 Wesley13
3年前
NGINX配置入门
Nginx是一个轻量级高性能的web服务器,它是为快速响应大量静态文件请求和高效利用系统资源而设计的。与apache使用面向进程或线程的方式处理请求不同,nginx使用异步事件驱动模型在负载下性能更突出。虽然nginx能高效地服务静态文件,但也有人认为nginx处理动态内容并不理想。不像apache服务器,nginx没用使用内嵌解释器的方式来处理动态内容
Stella981 Stella981
3年前
Android异步操作总结
Android中经常会有一些操作比如网络请求,文件读写,数据库操作,比较耗时,我们需要将其放在非UI线程去处理,此时,我们需要处理任务前后UI的变化和交互。我们需要通过类似js中异步请求处理,这里总结我所了解到的,方便自己记忆,也方便别人的浏览。1.AsyncTasknewAysncTask().execute();AsyncTask会
Stella981 Stella981
3年前
OkHttp请求耗时统计
目录介绍01.先提问一个问题02.EventListener回调原理03.请求开始结束监听04.dns解析开始结束监听05.连接开始结束监听06.TLS连接开始结束监听07.连接绑定和释放监听08.request请求监听09.response响应监听
Stella981 Stella981
3年前
Play Framework2.1源码分析
_转载请注明出处,保持署名__作者:joymufeng_1. 介绍大家翘首以盼的Play2.1终于发布了,目前可用版本是Play2.1RC4。在此感谢Play!开发团队付出的辛勤努力!Play2.1以后版本中将会加入导出符合Servlet3.1规范的War
Stella981 Stella981
3年前
Redis学习笔记(五) 总结
为什么使用redis    改善性能。当大SQL执行耗时久,且结果不频繁变动,就特别适合将运行结果放入缓存,后面的请求从缓存中读取,使得请求能够迅速响应    缓解并发压力。大并发下,所有请求都是直接访问数据库的,会出现连接异常。redis做一个缓冲,让请求先访问redis,而不是数据库。
Stella981 Stella981
3年前
React Native 网络层分析
文:志俊(沪江Web前端)本文原创,转载请注明作者及出处在使用ReactNative开发中,我们熟练的采用JavaScript的方式发送请求的方式发送一个请求到服务端,但是处理这个请求的过程其实和处理Web应用中发送的请求的过程是不一样的。因为处理这个请求的目标不是浏览器,而是嵌入这个应用的原生操作系统。<!more
Stella981 Stella981
3年前
C++笔记002:VS2010报错:LINK fatal error LNK1123 转换到 COFF 期间失败文件无效或损坏
 原创笔记,转载请注明出处!点击【关注】,关注也是一种美德~错误描述:1已启动生成:项目:FirstCode,配置:DebugWin321生成启动时间为2018/2/521:00:30。1InitializeBuildStatus:1 正在
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究