twitter の速度について - 口内炎延焼
こちら側に十分に速いクライアントを用意した上で、 statuses/update やら favorites/create やらを数万回から数百万回ほど試行して速度を計測してみた。 update は基本的に 500ms 程かかる。これには Request や Response のオブジェクト等の組み立てを含まない。 OAuth で認証する場合など Request の組み立てコストが高いので、感覚としては 1 秒ぐらいかかる、ということになる。 favorites/create を今朝 3 万回程試行したところ 190ms ほどで fav をつけられることが分かった。投稿より若干速い。 最適な並列数をこういったことから算出してゆきたい。 実験の残骸 http://favstar.fm/users/youpy/status/20124150089 http://favstar.fm/users/
Ruby どうでもいい知識シリーズ - Candy
em-http-request は環境にもよるが 200 並列ぐらいから急激に遅くなる(あるいは落ちる)ので 150 並列ぐらいまでしか安定運用は出来ない thread と Net::HTTP で並列アクセスをする場合、 request および response の組み立てはスケールしないが純粋な HTTP 部分だけはスケールする thread を使う場合 8,000 並列ぐらいまでは順調にスケールする。それ以上は req と res の組み立てがあるので無駄になる事例が多い。相手のサーバーの速度と req と res の組み立てコストから最適解を計算しよう Ruby 1.9 でスレッドを 3000 個ぐらい作ると止まる。 Ruby 1.8 では 16,000 個ぐらい作っても止まらない 以上なるほど四時じゃねーので培った Ruby に関する知識です。
クラウド破産しました - Candy
EC2 で大量のストレージを借りてさまざまな実験を繰り返していたら、僅か数日で 25 万円もの課金が発生しました。 まあ大規模課金が発生したということそのものは、俺がアホでしたで済む話なんですが、課金額の相当分を EBS の I/O Request が占めている感じです。 EBS を使うさいは事前に I/O がどれくらい発生するか正確に見積もる必要があるでしょう(だけどこれ難しいよね)。
Amazon EC2 のロードバランサーを快適に使う方法 - 野菜
Amazon EC2 のロードバランサーは狂っている。一定時間リクエストが無かった場合、次回のリクエストに 502 を返すことがある。 これを防ぐ方法。 定期的に適当なサーバーから wget する。 死ね糞が。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
