Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ
Perlでコマンドラインオプションをparseしようと思うと組込みモジュールとしては Getopt::Std と Getopt::Long がある。が、long style option *1 つまり --option-name のようなオプションを解釈してくれるのは Getopt::Long だけだ。なので普通はこちらを使おう。 ただし 絶対にデフォルト、つまり以下のようにして使ってはいけない。 use Getopt::Long; my (@primary, @secondary, $silent); GetOptions( "server-primary|p=s" => \@primary, "server-secondary|s=s" => \@secondary, "silent|S" => \$silent ); これダメ！ 絶対ダメ！ 死ぬ！ 最初に結論を書く 必ず以下のように
fluentd のベンチマークとってみたよ！ - たごもりすメモ
入出力プラグインをrubyで書けるのがじつにいい感じの fluentd がいい感じに見える。 fluent/fluentd · GitHub ので使えるかどうか、使えるとしたらどれくらいのノードを用意すればいいのかについて考えるため、とりあえずベンチマークをとってみた。 結論 以下非常に長くなるので結論だけ書くと、大変使える感じ。現状だとほとんど何も考えずにデータ中継させても秒間1万メッセージ、100Mbpsくらいまでは処理できる。効率よくなるよう流す側も考えてやれば 300Mbps を超えるデータの転送に成功した。だいぶいい感じ。 なおこれは in_scribe および out_scribe を使用した場合で、開発者 @frsyuki によるとMessagePackでのデータ転送の場合はこの倍くらい出るらしい。 もちろんこれは右から左に流しただけなので現実にタグによるルーティングだとかロ
fluentdのためのプラグインをイチから書く手順 - たごもりすメモ
(2012/02/21追記: bundle gem して作成する手順をこっちに書いた http://d.hatena.ne.jp/tagomoris/20120221/1329815126 ) fluentdがいい感じでパフォーマンスにも問題ない状況になってきたように見えるので、よっしゃいっちょプラグインでも書くか！ と思ったもののリポジトリをgithubに作ったはいいがコード書いてテストしてgemとしてリリースするまでには様々にめんどくさいことがあり gem とか作ったことない自分*1には摩訶不思議なあれやこれやが広がっていてコード書くところに辿りつくまでが長過ぎるというか、端的に言ってあちこちに散在する情報を集めるのに必要な時間とともにやる気がとめどなく流出していってもうだめだという気分になる。 というような主旨のtweetをしてみたもののどうにかなるわけでもないので、試行錯誤しながら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
