(スープ)カレーはさいきょうのたべもの

前置き

この記事はカレー Advent Calendar 2013 23日目の記事です。昨日の記事はtan_go238さんの空堀の旧ヤム邸にカレーを食べに行ってきました。でした。

(スープ)カレーはさいきょうのたべもの

カレー!!私が自炊においてカレーが最強の食べ物だと確信した経緯をお話します。それは私が大学に入学し一人暮らしあーんど自炊を始めた頃のお話です・・・。

自炊を始めた最初の一週間では、手間の問題からまず素材(じゃがいもや肉、もやしなどを)を蒸すなりチンするなり焼くなりしてそのまま食べていました。しかしさすがに一週間かそこらで素材そのままの味ではキツくなっていきました。もやしを何も付けずに食べるのは非常に大変なものがあります・・・。

次に調味料を買い素材に付けるようになり、更に一週間ほど凌ぐことが出来ました。しかしこの頃調理が面倒になっていました。調理する時にずっと炒めるなりなんなり手を動かさないとならないのは非常に手間だと。

そこで次の一週間では煮込み料理であるポトフを作るようになりました。これは材料を洗って切って全部鍋にぶち込んで煮ればいいので簡単です。ただそれでも面倒なので、一週間分を作り冷蔵庫に入れて毎日少しずつ食べていました。一週間の終わりには飽きてきました。

そして満を持して私の食生活のベストプラクティスが次の一週間に見つかりました。

それは(スープ)カレーです。

一週間の始めにスープカレーを作り冷蔵庫に入れて少しずつ消費していきます。するとスープカレーは数日で水分が少なくなりまるでカレーのようになります。更に週の終わりには更に水分が少なくなりドライカレーのようになります。

スープカレー→カレー→ドライカレー

これが私の自炊における最高の方程式です。 ありがとうございました。

最高のカレーにしようぜ!

以下はせっかくなので今日食べたゴーゴーカレーですが、自分の作るカレーとは違い具が見当たりませんでした。自炊カレー食べたいなぁ・・・。

f:id:anoworl:20131223130031j:plain

後置き

明日はsyo_sa1982さんです!!

カッティングプロッタで羽の様な名刺を創ろう

前置き

FuniSaya Advent Calendar 2013 11日目です!昨日はкёкуさんの荒木良造・著「姓名の研究」を読んだので感想を書いてみた~FuniSaya Advent Calendar 2013 10日目でした!

はじめに

好きなモノは創りたい。私の行動原理。

過程

好きなモノ

これのみゲームのスクリーンショットユメミルクスリより転載。

f:id:anoworl:20131211232114j:plain

きっかけ

f:id:anoworl:20131211232228j:plain

ラフ

f:id:anoworl:20131211232243j:plain

デジタル

f:id:anoworl:20131211232316j:plain

パス化

f:id:anoworl:20131211232413j:plain

テスト出力

f:id:anoworl:20131211223611j:plain

名刺サイズ

f:id:anoworl:20131211232605j:plain

思いつき

f:id:anoworl:20131211232816j:plain

量産

f:id:anoworl:20131211232841j:plain

ふへへ

f:id:anoworl:20131211232913j:plain

かんせー!

f:id:anoworl:20131211232923j:plain

後置き

明日はUSAMI Kentaさんです!

Railsアプリケーションにおけるパフォーマンス測定について調査

背景

Heroku上でRuby on Railsを使い作成したウェブアプリケーションを運用している。しかしアプリケーションの一つの機能である画像のアップロードについてレスポンス時間が長く、ボタンの二度押しや複数同時アクセスがあった時に応答が返ってこないことやアップロードに失敗することがある。そこを解決するためにこのアプリケーションのパフォーマンスチューニングを行うが、定量的な測定が出来なければ改善したかどうかが施策後曖昧になってしまい、目標を達成できたのか(いつどこで施策をやめるのか)、どの施策が有効だったか分からず今後に活かせないことが考えられる。そこでここではRailsアプリケーションにおけるパフォーマンス測定について調査する。

他に参考にした記事

Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました | クックパッド開発者ブログ

RubyKaigi 2013で発表されたクックパッドの社員の方によるRailsアプリケーションチューニングについての資料。最近の資料でありRailsを大規模に使っているクックパッドの事例なので、とても資料価値が高いように思われる。

rails/rails-perftest

Rails 4にてgemに切りだされたパフォーマンス測定ライブラリ。

newrelic/rpm

New Relicでの測定が優れているという噂。Developer ModeとProduction Modeで表示される情報が違うらしい。

#368 MiniProfiler - RailsCasts

日本語の資料です。主にSQLクエリのプロファイリングを行うことができます。

#411 Performance Testing (pro) - RailsCasts

RailsCastsの有料記事です。

指標

チューニングする値について

サーバ側でチューニング可能な、リクエストが最後までサーバに辿り着いてから、サーバがレスポンスをクライアントに向けて送信し始めるまでの時間のチューニングを行う。ここではDOMのレンタリング時間や複数のコネクションを張ることによる遅延時間は対象に含めない。またクライアントから送られるデータのサイズによるネットワークの遅延時間も対象とならない。

レスポンスタイム(応答時間)の定義について

例えばクックパッドでは200ms以下にレスポンスタイムを抑える目標を持っていますが、この「レスポンスタイム」とはどのように計測したものなのか、まず考察しました。どうやら先日行われたRubyKaigi 2013でのIssei Narutaさんのスライドを見るに、前項での定義と同じだと思いました。よってここでもその定義に従おうと思います。 ただ一部でクライアントがレスポンスを受信するまでの時間と定めている記事があり、これはネットワークでのデータ送受信にかかる時間が含まれ前述のレスポンスタイムの定義とは異なることから、各々の記事でどのようにレスポンスタイムが定義されているかについては、意識しなければならないと思いました。(情報処理試験における定義ISO/IEC9126における定義についても面白かったです)

実際

Apache JMeterで規定のリクエストを30回行い、サーバ側でレスポンスタイムを測ると共にJMeerでサンプルタイムを測り、それらの値をグラフ化及び平均化し比較及びチューニングを行った。

HerokuのRequest queuingについて調査

背景

Heroku上のRailsアプリで容量の大きい画像をアップロードする際、ボタンを連打するとレスポンスが全然返ってこなくなりました。New Relicを見てみると、Request queueingという処理に50秒ほど取られていることが判明。その解決方法を調べるため、文献を調査しました。

主に参考にした記事

Dynos and the Dyno Manager | Heroku Dev Center

Dynos and requests

A single dyno can serve thousands of requests per second, but performance depends > greatly on the language and framework you use.

A single-threaded, non-concurrent web framework (like Rails 3 in its default configuration) can process one request at a time. For an app that takes 100ms on average to process each request, this translates to about 10 requests per second per dyno, which is not optimal.

Single threaded backends are not recommended for production applications for their inefficient handling of concurrent requests. Choose a concurrent backend whenever developing and running a production service.

Multi-threaded or event-driven environments like Java, Unicorn, EventMachine, and Node.js can handle many concurrent requests. Load testing your app is the only realistic way to determine request throughput.

推測

要はUnicornに切り替えれば良い気がしました。

以下は他に参考にした文献です。結構面白い。

他に参考にした記事

HTTP Routing | Heroku Dev Center

Request queueing

Each router maintains an internal per-app request queue. For Cedar apps, routers limit the number of active requests per dyno to 50 and queue additional requests. There is no coordination between routers however, so this request limit is per router. The request queue on each router has a maximum backlog size of 50n (n = the number of web dynos your app has running). If the request queue on a particular router fills up, subsequent requests to that router will immediately return an H11 (Backlog too deep) response.

Simultaneous connections

The herokuapp.com routing stack allows many concurrent connections to web dynos. For production apps, you should always choose an embedded webserver that allows multiple concurrent connections to maximize the responsiveness of your app. You can also take advantage of concurrent connections for long-polling requests.

Almost all modern web frameworks and embeddable webservers support multiple concurrent connections. Examples of webservers that allow concurrent request processing in the dyno include Unicorn (Ruby), Goliath (Ruby), Puma (JRuby), Gunicorn (Python), and Jetty (Java).

Request Timeout | Heroku Dev Center

Request queueing efficiency

Request timeouts can also be caused by queueing of TCP connections inside the dyno. Some languages and frameworks process only one connection at a time, but it’s possible for the routers to send more than one request to a dyno concurrently. In this case, requests will queue behind the one being processed by the app, causing those subsequent requests to take longer than they would on their own. You can get some visibility into request queue times with the New Relic addon. This problem can be ameliorated by the following techniques, in order of typical effectiveness:

  • Run more processes per dyno, with correspondingly fewer dynos. If you’re using a framework that can handle only one request at a time (for example, Ruby on Rails), try a tool like Unicorn with more worker processes. This keeps your app’s total concurrency the same, but dramatically improves request queueing efficiency by sharing each dyno queue among more processes.
  • Make slow requests faster by optimizing app code. To do this effectively, focus on the 99th percentile and maximum service time for your app. This decreases the amount of time requests will spend waiting behind other, slower requests.
  • Run more dynos, thus increasing total concurrency. This slightly decreases the probability that any given request will get stuck behind another one.

Heroku | Better Queuing Metrics With Updated New Relic Add-On

Heroku Queuing Time, Part1: Problem | Railsware Blog