循环放在 View 里面的日志

Started GET "/" for 127.0.0.1 at 2012-11-24 22:20:45 +0800
Processing by MainController#index as */*
  Rendered main/index.html.erb within layouts/application (1670.9ms)
Completed 200 OK in 1873ms (Views: 1672.4ms | ActiveRecord: 0.0ms)

移出后的日志

Started GET "/" for 127.0.0.1 at 2012-11-24 22:23:24 +0800
Processing by MainController#index as */*
  Rendered main/index.html.erb within layouts/application (1.6ms)
Completed 200 OK in 410ms (Views: 3.1ms | ActiveRecord: 0.0ms)

可见效率是有差异的。不过我觉得一般不会用到 128000 这么大的循环，View 按正常写就行了。

测试了一下，用 passenger start -p 4000 -e production --max-pool-size 100 --min-instances 10 启动

ab -c 10 -n 100 http://localhost:4000/

按原文的代码

Server Software:        nginx/1.2.3
Server Hostname:        localhost
Server Port:            4000

Document Path:          /
Document Length:        512451 bytes

Concurrency Level:      10
Time taken for tests:   21.563 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      51319400 bytes
HTML transferred:       51245100 bytes
Requests per second:    4.64 [#/sec] (mean)
Time per request:       2156.277 [ms] (mean)
Time per request:       215.628 [ms] (mean, across all concurrent requests)
Transfer rate:          2324.22 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:  1273 2107 311.6   2128    2994
Waiting:     1273 2106 311.6   2128    2994
Total:       1273 2107 311.7   2128    2994

Percentage of the requests served within a certain time (ms)
  50%   2128
  66%   2290
  75%   2336
  80%   2362
  90%   2460
  95%   2544
  98%   2747
  99%   2994
 100%   2994 (longest request)

把 view 里面的循环移到 controller

class MainController < ApplicationController
  def index
    sleep(0.2)
    @content = 128000.times.map{rand(8999)+1000}.join
  end
end

<%= @content %>

结果有了不少改善

Server Software:        nginx/1.2.3
Server Hostname:        localhost
Server Port:            4000

Document Path:          /
Document Length:        512451 bytes

Concurrency Level:      10
Time taken for tests:   4.817 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      51319400 bytes
HTML transferred:       51245100 bytes
Requests per second:    20.76 [#/sec] (mean)
Time per request:       481.690 [ms] (mean)
Time per request:       48.169 [ms] (mean, across all concurrent requests)
Transfer rate:          10404.33 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:   363  466  97.4    442     768
Waiting:      362  465  97.2    442     768
Total:        363  466  97.4    442     768

Percentage of the requests served within a certain time (ms)
  50%    442
  66%    480
  75%    502
  80%    513
  90%    593
  95%    735
  98%    767
  99%    768
 100%    768 (longest request)

结论是

1. View 里的循环多花了很多时间
2. 他的电脑没我的快

#26 楼 @QueXuQ 我就普通毕业的。因为没想好要做什么，毕业就在家想了半年。

用系统的 https://github.com/javan/whenever

#22 楼 @DoIT 写代码，思考人生。

#15 楼 @QueXuQ 毕业后家里蹲了半年。

我是毕业半年后才找工作，没提三方协议。

#11 楼 @QueXuQ 这真诡异了，production 和 development 是用同样的数据库吗？database.yml 里面有设置编码的项，数据库也有几个编码设置，都统一 utf-8。

#9 楼 @QueXuQ 顺着 javascript 的 link 看能不能打开，在控制台调用 js 里定义的 function 看能不能调用。

还有一个可能是浏览器缓存，chrome 的控制台右下角配置里面有 disable cache 选项。

#6 楼 @QueXuQ 没有用 git？

#6 楼 @QueXuQ 本机几乎不跑生产模式。除非发现了开发模式正常，生产模式出 bug 了才会去调试生产模式。

本机，开发模式 -> 测试服务器，生产模式，5 分钟自动部署 -> 线上服务器，生产模式，手动部署

有对应 Model 的时候用 form_for，没有就用 form_tag，比如搜索框一般没有对应 Model。

查了一下，gnome 原生没带桌面小部件的机制，还得额外装应用 http://askubuntu.com/questions/4683/does-gnome-support-desktop-widgets

桌面开发选择余地其实不多，先看要对应什么桌面，桌面提供了什么编程环境，然后这个编程环境有什么语言绑定。

我曾经想用 Ruby 写 kde plasma 的部件，发现 Ruby 绑定不完善，后来不了了之了。

还要看哪个桌面环境。

赞成。

怎么没人回答，没人懂吗？！

看来要多看国外视频，不然连读错了都不知道。我一直读 catch。

是不是明年要预备 showboy 了。

马桶……

如果这时候……

#6 楼 @AlphaLiu 那么，为什么更新 email 的时候 password 校验会通不过？