看板
[ Ruby ]
討論串Ruby on Rails 的速度議題
共 19 篇文章
內容預覽:
我同意其他的部分都有可議之處，事實上我覺得「詮釋」是一回事，能否找出什麼情況下誰比較好用以利選擇，才是對一般開發者有幫助的事。. 以下這一段我有些疑問。. 雖然評估效能的指標是時間，可是這裡的平均處理時間的量級看起來比較像 CPU time?. 由於您是以 Google Analytics 的數據來
(還有355個字)
內容預覽:
我們系統後端有頁面處理時間的Log,會提供人數是要表達. 像JavaEye的用戶數跟主機. 我們用戶數稍微多一點點,主機稍微差一點點,但是處理速度仍然不差. 並非直接拿什麼東西除以什麼我為何提到處理時間. 是剛好看到javaeye同樣也提供了rails處理時間. 如果要加上使用者的"感覺"那就必須想
(還有394個字)
內容預覽:
我仍然覺得有些困惑。. 所以您的「處理時間」是像 JavaEye 的分類法那樣，去掉 DB 的部分，當然也不算網路？. 以前我自己測東西的時候，為了讓整個 wall clock time 最接近使用者的感覺，. 會想辦法走 localhost 或在區域網路內，用 MS Web Application
(還有444個字)
內容預覽:
我確實沒有用stress tool測試過. 只看log,而log是實際現在上線,從收到request到response的時間. 所以是包含db的.當然..這沒有網路傳輸時間.. 有機會我在試試看有沒有辦法使用stress tool測試了,因為現在機器不是放在身邊我自己沒碰過tapestry,所以我不
(還有94個字)