英文:
Why is Go's Martini less performant than Play Framework 2.2.x
问题
我在Golang+Martini和Play Framework 2.2.x中编写了两个相同的项目，以比较它们的性能。两者都有一个渲染10K HTML视图的动作。使用ab -n 10000 -c 1000进行测试，并通过ab输出和htop监控结果。两者都使用生产配置和编译视图。我对结果感到好奇：
Play Framework：~17000 req/sec + 我的i7所有核心持续100%使用率 = ~0.059毫秒/req
Martini：~4000 req/sec + 我的i7所有核心持续70%使用率 = ~0.25毫秒/req
...我理解Martini并不臃肿，那为什么它要慢4.5倍？有没有办法加速？
更新：添加了基准测试结果
Golang + Martini:
./wrk -c1000 -t10 -d10 http://localhost:9875/
在 http://localhost:9875/ 上运行10秒测试
10个线程和1000个连接
线程统计 平均值 标准差 最大值 +/- 标准差
延迟 241.70毫秒 164.61毫秒 1.16秒 71.06%
每秒请求数 393.42 75.79 716.00 83.26%
10秒内的请求数: 38554，读取了91.33MB
Socket错误: 连接 0，读取 0，写入 0，超时 108
每秒请求数: 3854.79
每秒传输数据: 9.13MB
Play!Framework 2:
./wrk -c1000 -t10 -d10 http://localhost:9000/
在 http://localhost:9000/ 上运行10秒测试
10个线程和1000个连接
线程统计 平均值 标准差 最大值 +/- 标准差
延迟 32.99毫秒 37.75毫秒 965.76毫秒 85.95%
每秒请求数 2.91k 657.65 7.61k 76.64%
10秒内的请求数: 276501，读取了1.39GB
Socket错误: 连接 0，读取 0，写入 0，超时 230
每秒请求数: 27645.91
每秒传输数据: 142.14MB
Martini运行时使用了runtime.GOMAXPROCS(runtime.NumCPU())
我想在生产中使用Golang，但在进行了这个基准测试之后，我不知道如何做出决策...
有没有办法加速？
英文:
I wrote two equal projects in Golang+Martini and Play Framework 2.2.x to compare it's performance. Both have 1 action that render 10K HTML View. Tested it with ab -n 10000 -c 1000 and monitored results via ab output and htop. Both uses production confs and compiled views. I wonder about results:
Play: ~17000 req/sec + constant 100% usage of all cores of my i7 = ~0.059 msec/req
Martini: ~4000 req/sec + constant 70% usage of all cores of my i7 = ~0.25 msec/req
...as I understand martini is not bloated, so why it 4.5 times slower? Any way to speedup?
Update: Added benchmark results
Golang + Martini:
./wrk -c1000 -t10 -d10 http://localhost:9875/
Running 10s test @ http://localhost:9875/
10 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 241.70ms 164.61ms 1.16s 71.06%
Req/Sec 393.42 75.79 716.00 83.26%
38554 requests in 10.00s, 91.33MB read
Socket errors: connect 0, read 0, write 0, timeout 108
Requests/sec: 3854.79
Transfer/sec: 9.13MB
Play!Framework 2:
./wrk -c1000 -t10 -d10 http://localhost:9000/
Running 10s test @ http://localhost:9000/
10 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 32.99ms 37.75ms 965.76ms 85.95%
Req/Sec 2.91k 657.65 7.61k 76.64%
276501 requests in 10.00s, 1.39GB read
Socket errors: connect 0, read 0, write 0, timeout 230
Requests/sec: 27645.91
Transfer/sec: 142.14MB
Martini running with runtime.GOMAXPROCS(runtime.NumCPU())
I want to use golang in production, but after this benchmark I don't know how can I make such decision...
Any way to speedup?
答案1
得分: 2
我用一个渲染1个HTML文件的简单马提尼应用程序，并且速度相当快：
✗ wrk -t10 -c1000 -d10s http://localhost:3000/
在 http://localhost:3000/ 上运行了10秒的测试
10个线程和1000个连接
线程统计 平均值 标准差 最大值 +/- 标准差
延迟 31.94毫秒 38.80毫秒 109.56毫秒 83.25%
请求/秒 3.97k 3.63k 11.03k 49.28%
10.01秒内的235155个请求，31.17MB读取
Socket错误：连接774次，读取0次，写入0次，超时3496次
请求/秒： 23497.82
传输速率： 3.11MB
Macbook pro i7.
这是应用程序的链接：https://gist.github.com/zishe/9947025
如果你展示你的代码会有帮助，也许你没有禁用日志或者漏掉了一些东西。
但是timeout 3496看起来不太好。
英文:
I made a simple martini app with rendering 1 html file and it's quite fast:
✗ wrk -t10 -c1000 -d10s http://localhost:3000/
Running 10s test @ http://localhost:3000/
10 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 31.94ms 38.80ms 109.56ms 83.25%
Req/Sec 3.97k 3.63k 11.03k 49.28%
235155 requests in 10.01s, 31.17MB read
Socket errors: connect 774, read 0, write 0, timeout 3496
Requests/sec: 23497.82
Transfer/sec: 3.11MB
Macbook pro i7.
This is app https://gist.github.com/zishe/9947025
It helps if you show your code, perhaps you didn't disable logs or missed something.
But timeout 3496 seems bad.
答案2
得分: 2
@Kr0e，没错！我发现在martini的依赖注入中过多地使用反射会导致性能下降。我转而使用gorilla mux，并编写了一些类似martini的辅助函数，得到了我想要的性能。
@Cory LaNou：我不能接受你的评论）现在我同意你的观点，生产环境中不使用框架是个好主意。谢谢
@user3353963：请看我的问题：两者都使用生产配置和编译视图。
英文:
@Kr0e, right! I figured out that heavy use of reflection in DI of martini makes it perform slowly.
I moved to gorilla mux and wrote some martini-style helpers and got a wanted performance.
@Cory LaNou: I can't accept yours comment) Now I agree with you, no framework in prod is good idea. Thanks
@user3353963: See my question: Both uses production confs and compiled views
答案3
得分: 1
抱歉，你的代码已经完成了。
请添加以下代码：
func init(){
martini.Env = martini.Prod
}
英文:
add this code:
func init(){
martini.Env = martini.Prod
}
sorry, your code have done.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论