Re: Ruby on Rails 的速度議題

看板Ruby作者kojilin (呵呵呵噗噗噗..搞笑..)時間18年前 (2006/10/21 19:45)推噓2(2推 0噓 3→)

留言5則, 2人參與討論串19/19 (看更多)

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