※ 引述《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)