Play Framework 平台的性能比较

测试环境说明：

用 Play! 框架随便弄一个简单的应用，然后分别用 Play 自带的服务器运行，另外一种是发布成war并用tomcat来运行。

在我的笔记本上测试，没有连接任何数据库，只是简单的输出一个文本信息。

50 个并发，共10000个请求。

下面是详细的测试结果（请注意看红色粗体部分）：

1. Play!

C:\Users\Administrator>ab -c 50 -n 10000 http://liudong:9000/bye
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking liudong (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests


Server Software:        Play!
Server Hostname:        liudong
Server Port:            9000

Document Path:          /bye
Document Length:        4 bytes

Concurrency Level:      50
Time taken for tests:   52.854023 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3920000 bytes
HTML transferred:       40000 bytes
Requests per second:    189.20 [#/sec] (mean)
Time per request:       264.270 [ms] (mean)
Time per request:       5.285 [ms] (mean, across all concurrent requests)
Transfer rate:          72.43 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      0       6
Processing:   161  263  28.9    250     583
Waiting:      160  263  28.8    250     583
Total:        161  263  28.9    250     583

Percentage of the requests served within a certain time (ms)
  50%    250
  66%    254
  75%    264
  80%    298
  90%    302
  95%    306
  98%    335
  99%    355
 100%    583 (longest request)

2. Tomcat 的测试结果

C:\Users\Administrator>ab -c 50 -n 10000 http://liudong/bye
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking liudong (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        liudong
Server Port:            80

Document Path:          /bye
Document Length:        4 bytes

Concurrency Level:      50
Time taken for tests:   26.199498 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3870000 bytes
HTML transferred:       40000 bytes
Requests per second:    381.69 [#/sec] (mean)
Time per request:       130.997 [ms] (mean)
Time per request:       2.620 [ms] (mean, across all concurrent requests)
Transfer rate:          144.24 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   2.0      0      54
Processing:     2  129 211.3     93    3182
Waiting:        2  128 211.2     92    3182
Total:          2  129 211.3     93    3186

Percentage of the requests served within a certain time (ms)
  50%     93
  66%    135
  75%    158
  80%    171
  90%    201
  95%    288
  98%    642
  99%   1450
 100%   3186 (longest request)

这么简单的应用，性能居然差了一倍，看来 Play! 自带的用 MINA 实现的 Web 服务器性能一般。

 

不是mina的问题，是play实现的问题，需要修改两处代码，具体改哪儿等我找到了贴出来；改完后的性能我以前测试下来是差不多的

1、play不管有没有用数据库都会打开一个事务，把这个去掉性能会提高1倍

2、用prod运行性能会提高很多

 

是不是设置为prod模式了？如果打包成war的话，貌似是默认设置为prod模式，否则就是dev模式，性能是差别很大的。

公平起见，二者都是在 DEV 模式下测试的。

我也不认为是mina问题，应是mina设置不对，如线程池大小，这些mina应有设的

莫非我记错了？我记得使用war命令生成war包时必须是prod模式。何不测试以下prod模式？记得Google Grop上有人提过次问题。

我担心的是play里面，用到的groovy，python这些动态语言的实现，如果有必要的，能不能用java重写这部分实现，这些动态的跟java相比运行速度会不会有影响呢？

od模式下的性能数据呢？根据我的经验 MINA 实现的 Web 服务器比tomcat的性能好的多。

用play这个框架，怎么能监控到她最后生成的SQL？

如果实现一对多和或者多对多的关联对象，这样我取主对象的时候，但只想用到子对象中的一个字段，

play是不是把这两个对象的多有字段都取出来啊？

类似select a.* ,b.* from a,b where a.id=b.parent_id