<h3>tcpdump で特定ポートのパケットキャプチャをする</h3>
<p>必要な時に毎回毎回調べてる気がするので教えて貰ったコマンドメモ。</p>
<pre><code>tcpdump -i eth0 port 80 -s 0 -l -w - | strings
</code></pre>
<p>benrri</p>

tcpdump で特定ポートのパケットキャプチャをする必要な時に毎回毎回調べてる気がするので教えて貰ったコマンドメモ。tcpdump -i eth0 port 80 -s 0 -l -w - | stringsbenrri

tcpdump で特定ポートのパケットキャプチャをする

<h3>Google Chrome で JavaScript オン・オフ切り替えてアクセスしたい</h3>
<p>開発環境で JS オフ/オン切り替えてチェックしたい時があったので。</p>
<h4>/etc/hosts に追加</h4>
<p>適当に</p>
<pre><code>127.0.0.1 javascript.off.localhost
</code></pre>
<p>とか追加する</p>
<h4>Chrome の 設定 -> 高度な設定</h4>
<p>JavaScript の実行をホストごとに許可できる設定があるので、そこで javascript.off.localhost をブロックする</p>
<p>これでホストベースで制御できるようになったので、</p>
<ul>
<li><a href="http://localhost:3000/">http://localhost:3000/</a> (JS オン)</li>
<li><a href="http://javascript.off.localhsot:3000/">http://javascript.off.localhsot:3000/</a> (JS オフ)</li>
</ul>
<p>みたいにすぐ切り替えできる。</p>

Google Chrome で JavaScript オン・オフ切り替えてアクセスしたい開発環境で JS オフ/オン切り替えてチェックしたい時があったので。/etc/hosts に追加適当に127.0.0.1 javascript.off.localhostとか追加するChrome の 設定 -> 高度な設定JavaScript の実行をホストごとに許可できる設定があるので、そこで javascript.off.localhost をブロックするこれでホストベースで制御できるようになったので、http://localhost:3000/ (JS オン)http://javascript.off.localhsot:3000/ (JS オフ)みたいにすぐ切り替えできる。

Google Chrome で JavaScript オン・オフ切り替えてアクセスしたい

<p>先日のももクロハッカソンで出会った wantedly を作ってる仲さんが<br>
<a href="http://wantedly.com/jobs/977"><img src="http://cache.gyazo.com/7b2ea7a4c04a050c50df6959ce26360c.png" alt=""></a><br>
と言ってたので、面白そうなので wantedly を速くしてみました。</p>
<ul>
<li><a href="http://wantedly.com/">wantedly</a></li>
</ul>
<p>ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。</p>
<h4>アプリケーションサイドのチューニング</h4>
<p>初心者<a href="#f1" title="仲さんはプログラミング初めて一年、Rails 初めて数ヶ月ですが、Ruby の実装から html / css / js ほぼすべて一人で wantedly 作ってすごい…">*1</a>にありがちな問題として</p>
<ul>
<li>SQL に適切にインデックス張ってない</li>
<li>キャッシュすべき場所をキャッシュしていない</li>
<li>無駄なデータを引きすぎてる</li>
</ul>
<p>ことがよくあります。ので順に実装を見ていきました。</p>
<h5>SQLに適切なインデックスを張ってない</h5>
<p>張ってありました！びっくり！＼(^o^)／</p>
<h5>キャッシュすべき場所をキャッシュしていない</h5>
<p>Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HTTP を叩いてとっていたため、適切にキャッシュを入れました。これで1秒強ぐらい速くなりました。</p>
<h5>無駄なデータを引きすぎている</h5>
<p>うっかり全件データ(!) を引いていたり、引かなくて良いデータを引いていたり箇所をログと New Relic <a href="#f2" title="Heroku 無料で New Relic プラグインが使えて便利">*2</a>から見ていって直していきました。これでログインユーザが1-3秒ぐらい速くなりました。<br>
SQL のインデックス張ってない問題やこれの問題は、データが少ない当初は遅いと感じなくても、データが増えれば増えるほど徐々に重くなっていき、また開発環境では本番と異なるデータを使ってるため、データ量が少ないこともあるため、初心者には気づきにくい &#x26; どこを直したら良いか解らないといったことが発生しがちでしょう。</p>
<h5>結果</h5>
<p>約6倍速＼(^o^)／</p>
<p><img src="http://cache.gyazo.com/6d7960c467c48a5fb8b8c440f8d8e09f.png" alt=""></p>
<h4>体感速度のチューニング</h4>
<p>続いてユーザが実際に感じる速度を向上させました。</p>
<p>wantedly は heroku にあるためサーバが遠く、1ファイルの取得に 200ms-300ms のタイムラグが発生します。そのため、以下のアプローチをとりました。</p>
<h5>リダイレクトは極力減らす</h5>
<p>リダイレクトするとそれだけで200-300ms遅く感じてしまうため、よくクリックするリンクはリダイレクトで無く、URL の生成でちゃんとリダイレクト先を生成するように変更しました。</p>
<h5>静的ファイルをまとめる</h5>
<p>Rails 3.1 からは 3.1 の目玉機能の一つ、asset pipeline が利用できるようになり、何も考えなくともルールに従えば js / css ファイルを一つにまとめられるようになったため、Rails 3.0 系から Rails 3.1.0 にアップグレードして asset pipeline を有効化しました。なお Rails 3.1.0 化はコード上 Rails 本体を弄る等無理な書き方をしてなかったため、割とすんなりアップグレードできました。</p>
<p>なお、heroku で asset pipeline をうまく使うには memcached plugin を入れ</p>
<pre><code># production.rb
  config.serve_static_assets = true
  config.assets.compress = true
  config.assets.compile = true
</code></pre>
<p>と設定するとうまく動くと思います。</p>
<h5>静的ファイルをブラウザにキャッシュさせる</h5>
<p>いわゆる Expires / Cache-Control ヘッダの指定ですね。Rails 3.1 + Asset Pipipele + Heroku でうまくキャッシュさせるには</p>
<pre><code>config.assets.digest = true
</code></pre>
<p>で asset の URL が内容が変更があったら変わるようにし(じゃないとキャッシュされ続けるため)</p>
<pre><code>config.static_cache_control = "public, max-age=#{1.day}"
</code></pre>
<p>で、Rack の ActionDispatch::Static で Cache-Controle ヘッダをはかせるようにします。</p>
<h5>結果</h5>
<p>以前</p>
<p><img src="http://cache.gyazo.com/034114a69c805ac47f45d6c80b0a2bfd.png" alt=""></p>
<p>以後</p>
<p><img src="http://cache.gyazo.com/6b05fb4038f0c2f2da352f13279498c8.png" alt=""></p>
<p>ちょっとわかりにくいですが、青のラインが250msぐらい速くなり、体感的にもロードが速くなりました。特に Heroku のようなサーバが遠い場合は効果がだいぶ出ると思います。</p>
<h4>終わりに</h4>
<p>これ以上の高速化には国内のサーバにする &#x26; 動的では無いコンテンツにフロントでもう一段階ちゃんと Varnish 等を入れキャッシュ設計するが必要になりますが、それをするのはコストがかかりすぎるので、やるとしてもサービスがだいぶ伸びてからになると感じました。</p>
<p>あとよく Rails アプリ遅いと言われてますが、200ms 前後の速度でしたらサービスがだいぶ大きくならない限りは、Heroku 等の PaaS でも簡単に維持できるなぁと改めて感じました。<a href="#f3" title="200ms だと遅いという方も居ると思いますが、だいたい重いと感じるサービスはもっともっと処理コストがかかってると思うので…">*3</a></p>
<p>あとあと、初めてちゃんと Heroku 触ってみたんですがすごく良くできてますね。ただやっぱり太平洋超えるのは日本向けのサービスだとするとつらいなー、とも感じたので Heroku の ec2 の東京リージョン版が出たらより日本でも流行りそうですね〜。</p>
<p><a href="#fn1">*1</a>:仲さんはプログラミング初めて一年、Rails 初めて数ヶ月ですが、Ruby の実装から html / css / js ほぼすべて一人で wantedly 作ってすごい…</p>
<p><a href="#fn2">*2</a>:Heroku 無料で New Relic プラグインが使えて便利</p>
<p><a href="#fn3">*3</a>:200ms だと遅いという方も居ると思いますが、だいたい重いと感じるサービスはもっともっと処理コストがかかってると思うので…</p>

先日のももクロハッカソンで出会った wantedly を作ってる仲さんがと言ってたので、面白そうなので wantedly を速くしてみました。wantedlyちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。アプリケーションサイドのチューニング初心者仲さんはプログラミング初めて一年、Rails 初めて数ヶ月ですが、Ruby の実装から html / css / js ほぼすべて一人で wantedly 作ってすごい…にありがちな問題としてSQL に適切にインデックス張ってないキャッシュすべき場所をキャッシュしていない無駄なデータを引きすぎてることがよくあります。ので順に実装を見ていきました。SQLに適切なインデックスを張ってない張ってありました！びっくり！＼(^o^)／キャッシ

先日のももクロハッカソンで出会った wantedly を作ってる仲さんがと言ってたので、面白そうなので wantedly を速くしてみました。wantedlyちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。アプリケーションサイドのチューニング初心者仲さんはプログラミング初めて一年、Rails 初めて数ヶ月ですが、Ruby の実装から html / css / js ほぼすべて一人で wantedly 作ってすごい…にありがちな問題としてSQL に適切にインデックス張ってないキャッシュすべき場所をキャッシュしていない無駄なデータを引きすぎてることがよくあります。ので順に実装を見ていきました。SQLに適切なインデックスを張ってない張ってありました！びっくり！＼(^o^)／キャッシュすべき場所をキャッシュしていないFacebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HTTP を叩いてとっていたため、適切にキャッシュを入れました。これで1秒強ぐらい速くなりました。無駄なデータを引きすぎているうっかり全件データ(!) を引いていたり、引かなくて良いデータを引いていたり箇所をログと New Relic Heroku 無料で New Relic プラグインが使えて便利から見ていって直していきました。これでログインユーザが1-3秒ぐらい速くなりました。SQL のインデックス張ってない問題やこれの問題は、データが少ない当初は遅いと感じなくても、データが増えれば増えるほど徐々に重くなっていき、また開発環境では本番と異なるデータを使ってるため、データ量が少ないこともあるため、初心者には気づきにくい & どこを直したら良いか解らないといったことが発生しがちでしょう。結果約6倍速＼(^o^)／体感速度のチューニング続いてユーザが実際に感じる速度を向上させました。wantedly は heroku にあるためサーバが遠く、1ファイルの取得に 200ms-300ms のタイムラグが発生します。そのため、以下のアプローチをとりました。リダイレクトは極力減らすリダイレクトするとそれだけで200-300ms遅く感じてしまうため、よくクリックするリンクはリダイレクトで無く、URL の生成でちゃんとリダイレクト先を生成するように変更しました。静的ファイルをまとめるRails 3.1 からは 3.1 の目玉機能の一つ、asset pipeline が利用できるようになり、何も考えなくともルールに従えば js / css ファイルを一つにまとめられるようになったため、Rails 3.0 系から Rails 3.1.0 にアップグレードして asset pipeline を有効化しました。なお Rails 3.1.0 化はコード上 Rails 本体を弄る等無理な書き方をしてなかったため、割とすんなりアップグレードできました。なお、heroku で asset pipeline をうまく使うには memcached plugin を入れ# production.rb
  config.serve_static_assets = true
  config.assets.compress = true
  config.assets.compile = trueと設定するとうまく動くと思います。静的ファイルをブラウザにキャッシュさせるいわゆる Expires / Cache-Control ヘッダの指定ですね。Rails 3.1 + Asset Pipipele + Heroku でうまくキャッシュさせるにはconfig.assets.digest = trueで asset の URL が内容が変更があったら変わるようにし(じゃないとキャッシュされ続けるため)config.static_cache_control = "public, max-age=#{1.day}"で、Rack の ActionDispatch::Static で Cache-Controle ヘッダをはかせるようにします。結果以前以後ちょっとわかりにくいですが、青のラインが250msぐらい速くなり、体感的にもロードが速くなりました。特に Heroku のようなサーバが遠い場合は効果がだいぶ出ると思います。終わりにこれ以上の高速化には国内のサーバにする & 動的では無いコンテンツにフロントでもう一段階ちゃんと Varnish 等を入れキャッシュ設計するが必要になりますが、それをするのはコストがかかりすぎるので、やるとしてもサービスがだいぶ伸びてからになると感じました。あとよく Rails アプリ遅いと言われてますが、200ms 前後の速度でしたらサービスがだいぶ大きくならない限りは、Heroku 等の PaaS でも簡単に維持できるなぁと改めて感じました。200ms だと遅いという方も居ると思いますが、だいたい重いと感じるサービスはもっともっと処理コストがかかってると思うので…あとあと、初めてちゃんと Heroku 触ってみたんですがすごく良くできてますね。ただやっぱり太平洋超えるのは日本向けのサービスだとするとつらいなー、とも感じたので Heroku の ec2 の東京リージョン版が出たらより日本でも流行りそうですね〜。*1:仲さんはプログラミング初めて一年、Rails 初めて数ヶ月ですが、Ruby の実装から html / css / js ほぼすべて一人で wantedly 作ってすごい…*2:Heroku 無料で New Relic プラグインが使えて便利*3:200ms だと遅いという方も居ると思いますが、だいたい重いと感じるサービスはもっともっと処理コストがかかってると思うので…

A Day in the Life

tcpdump で特定ポートのパケットキャプチャをする

tcpdump で特定ポートのパケットキャプチャをする

書いている人

おたよりを送る