CarrierWave 导致的性能问题

gfreezy_ — Mon, 17 Dec 2012 23:41:02 +0800

Started GET "/" for 127.0.0.1 at 2012-12-17 23:39:21 +0800 Processing by TopicsController#index as HTML User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 Topic Load (0.2ms) SELECT "topics".* FROM "topics" LIMIT 12 OFFSET 0 Item Load (0.2ms) SELECT "items".* FROM "items" WHERE "items"."topic_id" = 2 ORDER BY item_votes_count desc LIMIT 9 (0.2ms) SELECT COUNT(*) FROM "topics" Rendered topics/index.html.erb within layouts/application (2047.6ms) Completed 200 OK in 2068ms (Views: 2056.1ms | ActiveRecord: 0.7ms)

View 有性能问题，用 Rack-mini-profiler 手动追踪，发现性能问题出在 CarrierWave 生成图片 URL 的地方，大家帮忙看看，怎么改或者怎么继续追踪下去？

CarrierWave 的 storage 用的是七牛。

怎么用 Ruby 的方式 (Block) 来实现这个递归

gfreezy_ — Sat, 15 Dec 2012 22:21:10 +0800

def get_all_friends(uid, client) friends = client.friendships.friends(uid: uid) total = friends.total_number get_friends(total, 0, uid, client) end

def get_friends(total, cursor, uid, client) left = total count = [200, left].min

friends = client.friendships.friends(uid: uid, count: count, cursor: cursor) left -= count next_cursor = friends.next_cursor

return friends if (left == 0 || next_cursor == 0)

more_firends = get_friends(left, next_cursor, uid, client) more_firends.users << friends.users return more_firends end

get_all_friends(uid, observer.client).users.map do |info| user = User.find_or_create_by_uid_and_name(uid: info.id, name: info.name) follow(user) user end

这段代码实现的是从微博获取所有关注（默认 API 只能根据 cursor 来一页一页的获取）。但是接触 Ruby 不久，不会用 Ruby 的方式（ block, do...end ）来实现。

然后因为一次获取其他也是靠 cursor 和 count 来定位的东西这种情况很普遍，可以通过将client.friendships.friends(uid: uid, count: count, cursor: cursor)这个提取出来，以函数的方式传进去（函数式的想法）的方法来抽象。

不知道 Ruby 的方式是怎么样来处理的？Ruby block的思想转不过来。

gfreezy_ (gfreezy)

CarrierWave 导致的性能问题

怎么用 Ruby 的方式 (Block) 来实现这个递归