第7回Rails勉強会@東京
第7回Rails勉強会@東京へ行ってきました。
第2回以来の久々の参加でした。何人か顔を覚えてくださっていた方もいらっしゃって前回よりも緊張せずに済みました。
パフォーマンスに関してのページを読む。
セッションの提案が滞っていたので一応他の人の意見を聞いてみようかなと印刷してきていたやつをセッションとして提案してしまいました。
InfoQ - Tracking change and innovation in the enterprise software development community
http://www.infoq.com/articles/Rails-Performance
Railsアプリで遅くなりがちな点について次のようなものがあげられています
- choosing a slow session container
- doing things on a per request basis, which could have been done once at startup
- repeating identical computations during request processing
- reading too often and too much from the database (especially in conjunction with associations)
- relying too much on inefficient helper methods
- 遅いセッションコンテナを使っている
- アプリを立ち上げた際に出来ることをリクエストのたびに行なっている
- リクエストの処理中に同じようなことを何度もやっている
- DBへのアクセスの回数が多すぎる
- helperの使いすぎで遅い
遅いセッションコンテナを使っている
- 速いセッションコンテナといえばSQLSessionStoreとMemCacheStoreがある。
- SQLSessionStoreを使えばActiveRecordStoreのトランザクションやcreate_on、update_atといったイベントを避けることが出来る。
- MemCacheStoreは30%ほどSQLSessionStoreよりも速い
- ただしEric Hodelさん作のmemcache cliantを使う必要がある。(Ruby-Memcacheは遅すぎる)
- このページの作者の人は開発の際にMemcacheは大げさだし色々めんどくさいのでDBベースのセッションストレージを使っているそうです。
アプリを立ち上げた際に出来ることをリクエストのたびに行なっている
- 恋塚さんによれば、ここで出ているコード見たいな感じのやつをlib/以下に書いておけばRailsプロセスを立ち上げた際に読むだけなので良いとのことです。Helper依存しすぎはよくないと。
リクエスト処理中に同じようなことを何度もやっている
- 例として挙げられているdetecting installed Ruby classes/modules using ObjectSpace.eachの意図がちょっと不明
クエリの最適化
Helper使いすぎ
- デフォルトのルーティングは最適化の余地があるのでよく使うものほど上におく方が少し速くなるそうな。
ActiveController::Routing::Routes.draw do |map| map.connect '', :controller => 'welcome" map.connect ':controller/sevice.wsdl', :action => 'wsdl' map.connect ':controller/:action/:id' end
- link_toは遅いのでHTMLで直接書いた方が良いよ。
- メンテコストが高くなるしBKくさいのでやらないよなぁ。
といった感じでした。id:ogijunさんによれば、こういうコードの最適化よりはスケーラビリティの面でのパフォーマンス云々の話の方が重要ということです。
自分がセッションを提案したのに全然オーナーとして知識も経験も不足していて参加された方には申し訳なかったです。
ARモデリング入門
セッションがなかなか出なかったので、Railsは使いやすいけど経験があまりないので実際どのようにモデルを作るかわからないと言ったらセッションになりました。
Yuguiさんとid:moroさんによるABDによるモデリング入門と言った感じでした。題材としてはソーシャルブックマークをモデリングしてみようという話でした。
まずPageとUserがいてそれらはリソース系のモデル。UserがPageをBookmarkするのでその間にイベント系のモデルBookmarkが出来る。テーブルの定義はこんな感じ。
create_table :users do |t| end create_table :pages do |t| t.column :url, :string, :null => false t.column :title, :string end create_table :bookmarks do |t| t.column :page_id, :integer, :null => false t.column :user_id, :integer, :null => false t.column :create_on, :timestamp, :null => false end
モデルは次のようになる。
class User < ActiveRecoard::Base has_many :pages, :through => :bookmarks has_many :bookmarks end class Page < ActiveRecoard::Base has_many :users, :through => :bookmarks has_many :bookmarks end class Bookmark < ActiveRecoard::Base has_many :users, :pages end
追記(06/06/20 08:17)
上の定義に誤りがありました。訂正します。
class User < ActiveRecord::Base has_many :pages, :through => :bookmarks has_many :bookmarks end class Page < ActiveRecord::Base has_many :users, :through => :bookmarks has_many :bookmarks end class Bookmark < ActiveRecord::Base belongs_to :user belongs_to :page end
まずリソース系のモデルを作成してテストをし、テストが通ったらイベント系のモデルを作成して実装していくといった感じにすると良いそうです。たしかにどこをどう組み立てたら良いのかが少しクリアになった気がするし、この書き方であれば一つのテーブルの定義は比較的単純で済むので拡張しやすいのかなと思いました。
ちょっと頭をひねったのが自己参照をする場合。UserがUserをお気に入りに加えるといった場合、Userの間にイベント系のFavoriteモデルを置いて、それをRailsで書くときにどうするのってことになりました。確かhabtm使うしかないんじゃないか的な話になったような気がするんですが、詳しいところは他の人の調べを待とうかと思います。
一次会
たまたま自分の卒論のテーマと似たようなことをやろうとしてる方がいてその人と色々話をしました。高橋さんの執筆経験の話はそこらへんにとても参考になりました。やっぱりモチベーションを保つことが重要で、それにはシステムだけにはどうしようもないところがあるよねってことのようです。
それから国内外でRails本ラッシュが起きそうだけど、実際初心者の人がそれを取って色々アプリを使っても簡単に動かせる環境がないんじゃあダメだよね。と話をして、国内のRailsホスティングサービスがやっぱりほしいなぁという話になりました。
二次会
先延ばしにされたはぶさんへの返答をみんなで考えました。いろいろネタが出ましたが、そこらへんはid:yad-ELさんの感想を参照してください。
http://d.hatena.ne.jp/yad-EL/20060618/1150648909
全体を通してのまとめ
- Keep
今回自分は積極的に関われたと思う
- Problem
なかなかセッションが上がらない。セッションを提案した人がオーナーになってしまうみたいなところが提案しづらいところではないか?
- Try
もうちょっとRailsを使い倒してネタを持っていけるようになる。ネタについていけるようになる。