※ 引述《kojilin (呵呵呵噗噗噗..搞笑..)》之铭言： : 我为何提到处理时间 : 是刚好看到javaeye同样也提供了rails处理时间 : 如果要加上使用者的"感觉"那就必须想到原po提到的瓶颈在哪 : 可能是网路传输时间,DB效能..等等,就像javaeye说他非常快, : 但是对於在台湾的我来说 : 连大陆我觉得不算快:)所以你的评估点在哪里呢? : 如果加上各种环境因素,我想这就不是你要表达的 : 因为你提到了"J2EE solution一直只能算是可接受的速度而已" : 而我也只是想回应你这句,Java并不慢,如此罢了 我仍然觉得有些困惑。 所以您的「处理时间」是像 JavaEye 的分类法那样，去掉 DB 的部分，当然也不算网路？ 以前我自己测东西的时候，为了让整个 wall clock time 最接近使用者的感觉， 会想办法走 localhost 或在区域网路内，用 MS Web Application Stress Tool 去打， 通常，我的评估点是这样来的。 若纯粹回到 JavaEye 定义的处理时间，他说： 「根据 log 显示，Ruby on Rails 处理通常在 0.03 ~ 0.05 秒 之内完成。」 这与您提到的数字的量级还算接近。 当然我同意，Java 并不慢，但就我最近半年学习 Tapestry 4.0 并以上述方法测试的 结果看来，恐怕还是「可接受」而不是快。原因或许也真如另一位网友所言，不少去藕合 的元件沟通成本高了一点点。因为我不用 OR mapping 只用 apache jdbc pool，以上述方 式从 local 进行压力测试，比较对象为 model 仍采用 apache library 但前端全部换成 PHP 的作法。这也是先前我为什麽说似乎是前端处理部分让人最有感觉的理由。没有在之 前就讲清楚，在此向大家道歉。<(_ _)> 啊，说穿了，这只是个案。所以其实我对谁快谁慢不是真那麽在乎。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.105.131.104 ※ 编辑: b6s 来自: 59.105.131.104 (10/21 18:56) ※ 编辑: b6s 来自: 59.105.131.104 (10/21 18:58)