Goで並列実行のベンチマークを取るためのライブラリ parallel-benchmark を書いた - 酒日記 はてな支店
以前 Perl で、forkして並列実行するベンチマークを取るためのライブラリ、Parallel::Benchmark というのを書きました。 Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店 これを使うと、単に Perl コードのベンチマークだけではなく、並列に外部にアクセスして計測を行うような (たとえばApacheBenchのような) ベンチマークツールが簡単に作れるので重宝しています。(仕事では、ソーシャルゲームのサーバアプリケーションに対する負荷テストを行うために使ったりもしています) で、思い立って Go 版を書きました。 kayac/parallel-benchmark · GitHub 使用例 フィボナッチ数を求めるコードを並列実行するベンチマーク fib(30) を1回計算するごとにスコア1とする 10個の goroutine
社内Gyazoの画像をAmazon S3に逃がしてスケーラブルに運用する - 酒日記 はてな支店
Gyazo、便利ですよね。大変便利なので、社内でプライベートなGyazoサーバを用意して使っている会社も多いと思います。 うちでもサーバのパフォーマンスは特に必要ないので社内に適当なVMを立てて運用していたのですが、数年単位で運用していると画像ファイルが増えていくためdiskをなんとかする必要に迫られました。 ここでどんどん増えるファイルはAmazon S3に逃がそう、という自然な発想に至るわけですが、Gyazoサーバアプリが投稿を受けたときにS3にアップロードするような改修をするのは年末の忙しい時期に面倒。楽したい。 ということで S3 と nginx を組み合わせていいかんじに運用できるようにしてみました。 Gyazoに限らず、 ローカルに書き込んだファイルをhttpで閲覧する 一度書き込まれたファイルには変更がない ファイルは消えないでどんどん増える ようなものには応用できると思いま
#isucon2 で優勝してきました - 酒日記 はてな支店
なんでもありのいい感じにスピードアップコンテスト ISUCON が 2 になって帰ってきたので、参加して優勝を勝ち取ってきました。 まとめ的なものはこちらから livedoor Techブログ : ISUCON チームメンバーのblogも併せてご覧ください。 おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました Redis布教活動報告 ISUCON 編 - unknownplace.org 今回は前回の ISUCON 優勝メンバーのひとり @sugyan が転職して出題側に回ってしまったので、@typester を招聘してチーム編成。@songmu と共に3人でチーム「fujiwara組」として再参戦です。 以下、作業用IRCのログからふりかえりますと…… 11:39:29 <typester> とりあえずrecent_soldはキャッシュってのはまずやることか
chef-solo + capistrano で複数ホストを管理する - 酒日記 はてな支店
chef-server は仕組みが大げさでインストールも大変だし、10〜20台ぐらいなら chef-solo と capistrano を組み合わせればいいよね？（同案多数） Capistranoとchef-soloを組み合わせて使う | ひげろぐ capistrano + chef-soloで構成管理する - delirious thoughts 実はこれまでもずっと、適当に書き殴った shell script で rsync && chef-solo 実行というのをやっていたのですが、複数の json をいい感じにマージして適用したかったので、capistrano で書き直してみました。 fujiwara/chef-solo-with-capistrano · GitHub 方針 cookbook などのファイルの同期は rsync で 共通で使用する json とホストごとにそれを上
[fluentd] #Fluentd Casual Talks で「fluentdでWebサイト運用を楽にする」話をしてきました - 酒日記 はてな支店
id:tagomoris さんにお声がけいただきまして、Fluentd Casual Talks にて「fluentdでWebサイト運用を楽にする」というタイトルで発表させていただきました。 発表資料はこちら 主催者の id:tagomoris さん、会場を提供していただいた DeNA 様、いろいろ準備をしてくださった id:riywo さんはじめ多くの方々、参加してくださった100名以上の皆様、ありがとうございました！楽しかったです。 発表ではここ半年ほど Fluentd を運用して来た経験をお話ししましたが、発表内で触れなかったことで大事(?)なことがありますので以下に補遺をいくつか書いておきます。 MongoDB にログを溜めすぎない方がいいかも 太田さん (@kzk_mover) の発表内でも触れられていましたが、数千万件程度にしておいたほうがいいのでは……という実感です。 発表内
fluent-plugin-zabbix リリース - 酒日記 はてな支店
fluentd の出力プラグイン、fluent-plugin-zabbix をリリースしました。 Github fujiwara/fluent-plugin-zabbix https://github.com/fujiwara/fluent-plugin-zabbix fluent-plugin-zabbix | RubyGems.org https://rubygems.org/gems/fluent-plugin-zabbix] 監視とメトリクス収集に Zabbix を使っているので、fluentd で収集した値を zabbix に送って扱いたかったのです。 挙動としては zabbix_sender でホスト側から送信するのと同様です。主に datacounter や flowcounter で集計した値を送るのを想定していますが、送信頻度に気をつければなんでも送れると思います。 作成
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
Go でテンプレートエンジン (json template) - 酒日記 はてな支店
http://d.hatena.ne.jp/tokuhirom/20091117/1258418742 をみて。 Go に付いてくるテンプレートエンジンは json-template て奴でした。 記法は リファレンス にありますが、テストケース を眺めると雰囲気がつかみやすいかも。 こんなコードを書いて package main import ( "template"; "os"; "io"; ); func main () { templateStr, _ := io.ReadFile("loop.tmpl"); templ := template.MustParse(string(templateStr), nil); params := new(struct { title string; messages [10]string }); params.title = "タイトル";
Go で http アプリケーションサーバ - 酒日記 はてな支店
デフォルトで付いてくるパッケージで、httpd (アプリケーション) が簡単に作れます。 import . "http" とすると、http. の前置なしで http パッケージの関数が使えるので、見た目も結構すっきり。 HandlerFunc(func(c *Conn, req *Request) { が繰り返されるのはちょっとうるさい感じですが。 # あとはテンプレートエンジンがあれば…… 付属してました → Go でテンプレートエンジン (json template) - 酒日記 はてな支店 http://gist.github.com/236088 package main import ( . "http"; // http パッケージの関数を http. prefix なしで使えるように "io"; "fmt"; ) func main() { gourl := "http:/
mod_xsendfile を使う - 酒日記 はてな支店
mod_xsendfile for Apache2/Apache2.2 という Apache モジュールがありまして、これを使うとレスポンスヘッダに X-Sendfile: path/to/file と出力することで、Apache がレスポンスのボディをファイルの中身で差し替えてくれる。 Webアプリケーションで認証後、大きなファイルをダウンロードさせるような用途に便利。 このモジュールはその名の通り sendfile システムコールを(使えれば)使うので、アプリケーションが自前でファイルの中身を読んで送信するよりも速い(軽い)はず。http://www.linux.or.jp/JM/html/LDP_man-pages/man2/sendfile.2.html ってことでベンチマーク取ってみた。 1. 普通に静的ファイルを Apache が serve 2. mod_xsendfile
Erlang で分散 ApacheBench もどき - 酒日記 はてな支店
書いてみた。どうも綺麗に書けてる気がしないのだが。(関数型の書き方に慣れてないのか……) ソースコードは末尾に。 HTTP のリクエストを並列に投げる部分はこんな感じで。 worker(): manager から URI を受け取って http:request()、結果を manager に戻す manager(): workerプロセスのリストを受け取って、それぞれの workerに仕事をやらせる / 完了したリクエストを数える / timer 処理 timer(): start / stop 間の経過時間を計る 複数ノード間で分散処理をするために必要な設定。 ホームディレクトリの .erlang.cookie ファイルの内容を同じにしておく。パーミッション 400 erl コマンドを -name 付きで起動する。 $ erl -name test Erlang (BEAM) emula
erlang で並列 HTTP request - 酒日記 はてな支店
まだ erlang の基礎もロクに勉強してないというのに、単に面白そうだから、という理由で並列プログラミングに手を出してみた。 HTTP get を複数の URL に対して並列で発行する。全体の構造は以下のようなもので。 main manager プロセスを作成 引数で受けた URL のリストから、ひとつの URL ごとに worker プロセスを作成 worker URL を HTTP GET して、結果を manager プロセスにメッセージ送信 manager workerプロセスから受けたメッセージを出力 erlang、さわって二日目だけどかなり取っ付きやすい印象。 , で区切ったのが順番に実行されるし、printf デバッグもできるし。 Erlangは関数型だけど難しくない: みかログ には全面的に同意。 -module(cohttp). -compile(export_all)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションのログについてあれこれ - 酒日記 はてな支店