作者kojilin (呵呵呵噗噗噗..搞笑..)
看板Ruby
标题Re: Ruby on Rails 的速度议题
时间Sat Oct 21 19:59:09 2006
※ 引述《b6s (http://b6s.blogspot.com)》之铭言：
: 我仍然觉得有些困惑。
: 所以您的「处理时间」是像 JavaEye 的分类法那样，去掉 DB 的部分，当然也不算网路？
: 以前我自己测东西的时候，为了让整个 wall clock time 最接近使用者的感觉，
: 会想办法走 localhost 或在区域网路内，用 MS Web Application Stress Tool 去打，
: 通常，我的评估点是这样来的。
: 若纯粹回到 JavaEye 定义的处理时间，他说：
: 「根据 log 显示，Ruby on Rails 处理通常在 0.03 ~ 0.05 秒 之内完成。」
: 这与您提到的数字的量级还算接近。
我确实没有用stress tool测试过
只看log,而log是实际现在上线,从收到request到response的时间
所以是包含db的.当然..这没有网路传输时间.
有机会我在试试看有没有办法使用stress tool测试了,因为现在机器不是放在身边
: 当然我同意，Java 并不慢，但就我最近半年学习 Tapestry 4.0 并以上述方法测试的
: 结果看来，恐怕还是「可接受」而不是快。原因或许也真如另一位网友所言，不少去藕合
: 的元件沟通成本高了一点点。因为我不用 OR mapping 只用 apache jdbc pool，以上述方
: 式从 local 进行压力测试，比较对象为 model 仍采用 apache library 但前端全部换成
: PHP 的作法。这也是先前我为什麽说似乎是前端处理部分让人最有感觉的理由。没有在之
: 前就讲清楚，在此向大家道歉。<(_ _)>
: 啊，说穿了，这只是个案。所以其实我对谁快谁慢不是真那麽在乎。
我自己没碰过tapestry,所以我不知道tapestry是否这麽慢
还是原因出在哪部分,或者你的压力测试确实让Java写的系统无法承受
既然是个案我想我也没办法提供什麽好方法帮你改进或有办法用说的就让你觉得快XD
我只是想帮忙平反"J2EE solution 一直都只能算是可接受的速度而已":P
"个案"怎麽会推到"一向"呢?
嗯~我没有意思抓小辫子或失言怎样,
只是想表达一下也是有人很"满意"的.
koji
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 218.167.165.115
1F：推 b6s:「一向」一辞确实不当。写下那段时我脑中浮现的是一些经验： 10/22 04:07
2F：→ b6s:四年前测 servlet engines 的 HTTP request, 10/22 04:08
3F：→ b6s:三年前测 SnipSnap 和 Jive，两年前测 Xwiki，今年测 Tapestry 10/22 04:08
4F：→ b6s:看来最近应该要再来做些严谨的测试了，不然总是一些模糊的回忆 10/22 04:09
5F：推 qrtt1:囧. 楼上测完如果有余力写点文章去发表:p 不然太可惜了 10/22 09:49