PlayFramework 2.1 技巧-性能调优实战

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

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

可以看出,在我们发送第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服务器内部错误“。

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
	  }
	}
  }
 }
}

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CaiRui

Python模块

简介: 模块:用一坨代码实现了某个功能的代码集合。分为三种: 自定义模块 第三方模块 内置模块 python去找模块的路径 ? 其中,第三方模块安装的位置 ? ...

2408
来自专栏逸鹏说道

★Kali信息收集~ 5.The Harvester:邮箱挖掘器

官网:http://www.edge-security.com 安装:apt-get install theHarvester 运行:终端输入 theharve...

3117
来自专栏技术博文

Linux下">/dev/null 2>&1 "相关知识说明

在学习Linux的过程中,常会看到一些终端命令或者程序中有 ">/dev/null 2>&1" 出现,由于已经遇到了好几次了,为了理解清楚,不妨花点时间百度或者...

30610
来自专栏Python

守护线程与守护进程

一 守护进程 主进程创建守护进程   其一:守护进程会在主进程代码执行结束后就终止   其二:守护进程内无法再开启子进程,否则抛出异常:AssertionErr...

3099
来自专栏Vamei实验室

来玩Play框架02 响应

我上一章总结了Play框架的基本使用。这一章里,我将修改和增加响应。 HTTP协议是按照“请求-响应”的方式工作。Play框架的核心是用动作(Action)来完...

2126
来自专栏JavaEdge

Redis 客户端服务端交互1 客户端/服务端协议

Redis实例运行在单独的进程中,应用系统(Redis客户端)通过Redis协议和Redis Server 进行交互

1012
来自专栏子勰随笔

SDK设计心得之版本号

3118
来自专栏自动化测试实战

flask第二十一篇——练习题

2486
来自专栏Android-薛之涛

Android-多线程

        通俗的说:我们平日里打开的QQ,微信,简书,都是一个进程。进程是程序的一次动态执行过程,它需要经历从代码加载,代码执行到执行完毕的一个完整的过程...

1012
来自专栏大数据智能实战

module 'tensorflow.python.framework.fast_tensor_util' does not match runtime version 3.6问题解决

最近在重新用tensorflow 1.3.*或者1.4 的时候,发现了好多问题,主要是碰到了如题目所示的问题,目前网上没有什么好的解决办法。 ? 关于这个问题,...

28010

扫码关注云+社区

领取腾讯云代金券