Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
Rils4で Russian Doll Caching を楽しむためのまとめ [俺の備忘録]
Google+ボタン はてなブックマークボタン 更新日時: 2014年01月11日（土） 作成日時: 2013年11月12日（火） 前の記事 / 次の記事 Rails4では従来の page cache や action cache は廃止され、 デフォルトのキャッシュ機構としては、Rails3までの fragment cache のようなものだけが使える。 Rails4のこのキャッシュ機構は今のところ RussianDollCaching、cache_digests、fragment cache 等と 呼ばれているみたいだけど指し示すものは全部同じもの。 というか最初別々の何かだと思ってて無駄に嵌まった。 Rails4で内部的に使われているgemが、 従来のRailsにおける fragment cache を進化させた cache_digests であり、 cache_digestsの仕組
LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster | Hacker News
If you are thinking about using node.js for this reason[1] on most sites, you are optimizing poorly. LinkedIn didn't worry about this until after they were a public company.If Python/Djando or Ruby/Rails can get your app out the door and into customer hands faster, it is almost always the right thing to use. 1. There are certainly other, very valid, technical reasons for choosing node.js over othe
Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました - クックパッド開発者ブログ
インフラストラクチャー部の成田です。 先日開催された RubyKaigi 2013 で、 "High Performance Rails" というタイトルの発表をしてきました。 スライドと動画 発表の様子は ustream の録画をご覧ください。 [ustream id=33559705 hwaccel=1 version=3 width=480 height=302] スライドは以下にアップロードしてあります。 High Performance Rails (long edition) // Speaker Deck なお、発表時間の都合上、当日はここから 40 枚ほどのスライドを削除してしまいました。発表に使った短いバージョンのスライドはこちらです。 発表の概要 クックパッドは 2008 年から Ruby on Rails を採用し、ずっと使い続けてきました。サービスが成長するとともに
How to Monitor Your Rails/Passenger App with Munin - Alfa Jango Blog
[caption id="attachment_70" align="alignleft" width="300" caption=" "][/caption] Munin is a great tool to monitor resources on your server, showing graphs over time, so that you can analyze resource trends to find what's killing your server before it causes major problems. It is also very configurable and can be made to profile and graph just about anything via plugins. And with a couple tricks, y
ActiveRecordが発行するSQLをフックして色々やるためのライブラリArproxyを公開しました - 昼メシ物語
https://github.com/cookpad/arproxy http://rubygems.org/gems/arproxy これは何？ Arproxyを使うと、ActiveRecordが発行したSQLがDB Adapterによって実行される直前をフックすることができます。これによって、カスタマイズしたクエリログを出力したり、どこからクエリが発行されたのかをトレースしたりすることができるようになります。 Arproxyでは、DB Adapterのフック処理を以下のように定義します。これはクエリが実行されるたびにバックトレースを出力する例です。*1 class QueryTracer < Arproxy::Base def execute(sql, name=nil) Rails.logger.debug sql Rails.logger.debug caller(1).join(
Rails Performance
The document provides performance best practices for Ruby on Rails applications. It discusses avoiding premature optimization, measuring performance bottlenecks, caching, SQL optimizations, and alternative storage options like NoSQL. It also recommends profiling tools like New Relic, Scout, Rack::Bug and ruby-prof to analyze logs and identify slow requests and actions. Benchmarking and integrating
UnicornとかRainbows!とかの話 : As Sloth As Possible
随分長いことブログ放置してしまったのだけどネタ見付けたので久々の記事。 UnicornはPassengerより遅かった？ なんかTwitterで「アクセス少ないときはPassengerよりUnicornのが速いのに、アクセス多くなってきたらその逆になった」って話をみかけたので、それ単にUnicornのworkerが足りないんじゃないの、と返したのだけど、どういうことかという話を少しまとめる。 まず、Unicornのworkerは1プロセスにつき1度に1リクエストしか処理しない。だから例えば、凄い大雑把な計算だけど、平均50msくらいでレスポンスを返すアプリだとすれば、1workerは20req/secくらいは返せるかなと見積もって、ピーク時に100req/secくらいアクセスがありそうだったらworkerを5個くらい立てとくかな、足んなかったらもうちょっとかな、みたいに考える。実際どんくら
Railsの各種サーバーの速度ベンチマーク: Pound、Varnish、Nginx、Unicorn、Mongrel
Railsの各種サーバーの速度ベンチマーク: Pound、Varnish、Nginx、Unicorn、Mongrel RailsのアプリをPound、Varnish、Nginx、Unicorn、Mongrelを使用して動かした際の速度ベンチマーク。以下の構成での同一Railsアプリをhttperfでベンチマークした結果をまとめます。 Pound -> Varnish -> Nginx -> Unicorn * 2 Varnish -> Nginx -> Unicorn * 2 Nginx -> Unicorn * 2 Mongrel (Rails.env == 'development') node.js (Express + Socket.IO) 全体の構成Poundを80番ポートを公開し、Varnishを81番ポート、nginxを8080番ポート、Unicornの2プロセスをsocke
ruby-profとKCacheGrindでプロファイル野郎になる - 昼メシ物語
速さが足りない！！！！！ そんな時はプロファイリングの時間ですね。 Rubyには標準添付ライブラリとして profile というプロファイラがついてくる。でもこのライブラリはあまりに遅すぎて実用に耐えないから、多分誰も使っていない。ほとんどのRubyistは ruby-prof を使っていることだろう。 今回はこの ruby-prof を使って Ruby プログラムのプロファイリングする方法を紹介する。 計測する（ruby-prof） ruby-profはrubygemsで簡単に入る。 $ gem install ruby-profruby-profというコマンドラインツールがインストールされる。これを使うと、プログラムを変更することなく手軽にプロファイリングを行うことができる。ruby-profコマンドのusageは以下のとおり。 ruby_prof 0.9.2 Usage: ruby_
RubyKaigi2010 に行ってきた(2, 3日目) - LukeSilvia’s diary
RubyKaigi2010 に行ってきた(1日目) - Slow Danceに続き、今年のRubyKaigi に行ってきたレポートを書きたいと思います!例によって興味があった内容をまとめました。Chad Fowler の基調講演の内容は情熱プログラマー ソフトウェア開発者の幸せな生き方を読むのが一番いいと思います。 また、内容に誤りがありましたらお手数ですが指摘いただけますと助かります。 Ruby powering 9 million dining tables(Cookpad) Cookpad CTO の橋本さん(@hashikem)によるCookpad のサービス、システム全般のお話と、id:secondlife さんが何故Cookpad に入社したかというお話を聴きました。 規模 9.89 M UU / month 83万レシピ 開発体制 ユーザにとって価値のあるものを作成するには
さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オシャレエロサイトをリリースして、10万PV/日を捌くためにやったこと - 彼女からは、おいちゃんと呼ばれています