YAPC::Kyoto 2023に参加しました #yapcjapan - 酒日記 はてな支店
blogを書くまでがYAPCということで、4年ぶりにオフライン開催されたhttps://yapcjapan.org/2023kyoto/:YAPC::Kyoto 2023に参加してきました。 YAPCは以前から年に1回の同窓会的な雰囲気があったのですが、今回は4年ぶりなので懐かしい顔がいっぱいでした。自分のようなベテランにはおなじみの顔だけではなく、初めての人も結構来ていたようで、コミュニティが世代を超えて広がっていく様子が感じられてよかったです。 自分の場合、参加したYAPCは喋ることのほうが多かったのですが、なんとなく若手に遠慮して(最近やったPerlネタもないし…)プロポーザルを出さなかったのはちょっと後悔しています。やっぱりカンファレンスは喋ってなんぼですからね。歳を取ってもまだまだ現役エンジニアなので、次はちゃんと出します。 カヤックブースではおみくじと絵馬を実施しました 聞いた
ISUCON11で優勝しました - 酒日記 はてな支店
勝った！！引退！！！ 取り乱しました。 ずっと参加してきているWebアプリケーションパフォーマンスチューニングコンテスト ISUCON、ISUCON11本選にチーム「fujiwara組」で参加して、優勝しました。 ISUCON11 まとめ : ISUCON公式Blog fujiwara組は初回のISUCONから参加している老舗チームで、自分(fujiwara)以外のメンバーは都度入れ替わっているのですが、今回はISUCON10の時と同様に会社(面白法人カヤック)の同僚である acidlemon と macopy とのチームです。 チーム紹介スライド 過去に ISUCON1, 2, 5 で優勝しているので、6年ぶり4度目の優勝になりました。もう引退していいよね！(というか941さんに出禁って言われた気がする…) やったこと リポジトリはこちらです。 github.com アプリケーションの変
Goで並列実行のベンチマークを取るためのライブラリ parallel-benchmark を書いた - 酒日記 はてな支店
以前 Perl で、forkして並列実行するベンチマークを取るためのライブラリ、Parallel::Benchmark というのを書きました。 Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店 これを使うと、単に Perl コードのベンチマークだけではなく、並列に外部にアクセスして計測を行うような (たとえばApacheBenchのような) ベンチマークツールが簡単に作れるので重宝しています。(仕事では、ソーシャルゲームのサーバアプリケーションに対する負荷テストを行うために使ったりもしています) で、思い立って Go 版を書きました。 kayac/parallel-benchmark · GitHub 使用例 フィボナッチ数を求めるコードを並列実行するベンチマーク fib(30) を1回計算するごとにスコア1とする 10個の goroutine
Redisを使って排他制御するwrapperコマンド Redis-Setlock をPerlとGoで書いた - 酒日記 はてな支店
しばらく前に作って書きそびれていましたが、Yokohama.pm #10 でLTしたのでエントリもあげます。 Perl版 https://metacpan.org/release/Redis-Setlock Go版 http://fujiwara.github.io/go-redis-setlock/ LTのスライドはこちら ⇒ Redis-Setlockを書いたはなし なにをするもの? 「setlockコマンドのロック処理をRedisサーバで行うもの」です。 setlockはflockを使ってロックを獲得したら引数に渡されたコマンドをexecする、daemontools付属のwrapperコマンドで、cronでコマンド実行するときなど多重実行を制御する場合に重宝します。 flockだとホストをまたいだロック処理が行えないため、その部分をRedisを使った排他制御に置き換えたものを書いてみ
YAPC::Asia 2013 で「社内ISUCONのつくりかた」を発表しました - 酒日記 はてな支店
blogを書くまでがYAPCということなので… YAPC::Asia 2013 にて「社内ISUCONのつくりかた」を発表しました。朝一の同時間帯に魅力的なトークがひしめくなか、聴きにきていただいた皆様ありがとうございます。 毎回40分のトークで早口になるので今年はゆるふわにするつもりだったのですが、蓋を開けてみたら結局いつもの感じになってしまいました。ゆるふわ難しい。 資料はこちらです 技術評論社さんのレポートも書いていただきました。ありがとうございます。http://gihyo.jp/news/report/01/yapcasia2013/0002 YAPC::Asia は2006年の初回から8年連続参加していて、うち本編トークは4年連続でやらせていただいていて、あらためてこう数えてみると結構な歴史を感じますね。 来年からはまた新しい歴史が始まることに期待して、一年間自分のできることを
ネットワークサーバじゃないプロセスでもServer::Starter経由で起動するといいことがあるかもという話 - 酒日記 はてな支店
具体的には Redis の subscriber なんですが、pub/sub の pub 側が publish し続けている状態で subscriber を再起動すると、落ちてから起動までの間に来たメッセージを取りこぼす可能性があります。 pub 側を一時停止すればいいのですが、fluent-plugin-redis_publish で fluentd から publish しているので、これを止めるのはあまりやりたくない。 複数の subscriber が同時起動して処理に問題が出ないように作られていることが前提ですが、新しい subscriber を起動したら古いのを殺すようにすればいいよね？ → それ Server::Starter でできるよ、という流れ。 $ start_server -- perl -e '$SIG{TERM}=sub{ warn "[$$] SIGTERM";
Redisでログの書き込みがblockを引き起こす - 酒日記 はてな支店
「RedisかわいいよRedis」(by typester)……というほど自分は Redis 期でもないのですが、最近 Redis を使ったサービスの面倒を見ていて時々レスポンスが悪化する現象に出会ったので調べました。 前提 使用しているのは Redis 2.4.16 です。 redis.conf に "save [t] [n]" を定義すると、最後に save をしてから [t]秒間に [n]個以上の key が更新された場合に background で save (=bgsave) が実行されます。 save 60 10000これだと、60秒間に 10,000 keys です。 bgsave では redisは自分自身のプロセスを fork() し、子プロセス側は自分のメモリに乗っている内容をファイルにすべて書き出します。 この仕組みによって、1プロセス 1スレッドで動作している re
YAPC::Asia 2012で「Webアプリケーションのベンチマークとプロファイリング」を発表しました - 酒日記 はてな支店
Perlのお祭りYAPC::Asia、今年もフルに参加して楽しんでいます。 初日のLT前に「Webアプリケーションのベンチマークとプロファイリング」というタイトルで発表しました。 発表資料はこちらです。 Webアプリケーションのベンチマークとプロファイリング 今回の発表の内容は 2012年10月発売予定の WEB+DB Press vol.71 「Perl Hackers Hub」でも掲載予定ですので、こちらも是非ご購入いただければと思います。 WEB+DB PRESS Vol.71 作者: 竹迫良範,Jxck,はまちや2,相澤歩,柴田博志,池田尚史,梅澤雄一郎,九岡佑介,近藤宇智朗,佐藤鉄平,mala,川添貴生,じょさん,後藤秀宣,藤原俊一郎,奥野幹也,堤智代,森田創,中島聡,A-Listers,WEB+DB PRESS編集部出版社/メーカー: 技術評論社発売日: 2012/10/24メ
cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
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 で集計した値を送るのを想定していますが、送信頻度に気をつければなんでも送れると思います。 作成
Parallel::Benchmark というモジュールを書きました - 酒日記 はてな支店
プロセスを並列に立ち上げて負荷を掛けるようなベンチマークを実行することって、よくありますよね。(例 : クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店) Perl で Parallel::ForkManager を使うとそういう処理も簡単に書けて便利なのですが、何度も同じようなコードを書くうちに、これもうちょっと抽象化したら使いやすいかも、と思って Parallel::Benchmark というモジュールを書いてみました。 リポジトリはこちらです。 https://github.com/fujiwara/p5-Parallel-Benchmark たとえばフィボナッチ数 fib(10) を求めるベンチマーク。 use Parallel::Benchmark; sub fib { my $n = shift; return $n if $n == 0 o
Perl から Fluentd にログ出力 - Fluent::Logger リリース - 酒日記 はてな支店
皆さん、ログ書いてますか！？(挨拶) Fluentd meetup in Japan も開催間近、最近大変熱いイベントログ収集システム Fluentd なわけですが、Perl からログを出力する Fluent::Logger というモジュールを CPAN にリリースしたのでお知らせします。 (最初の版は id:hirose31 さんが書かれて、それに同僚の id:shin1rosei と手を加えたものです) インストールは cpanm などでどうぞ。使い方は POD にもあるように簡単です。 use Fluent::Logger; my $logger = Fluent::Logger->new( host => "127.0.0.1", port => 24224 ); $logger->post( "myapp.info" => { foo => "bar" } ); 上記の例で送信す
クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
#isucon で優勝してきました - 酒日記 はてな支店
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
SIGNALを考慮してないTheSchwartz Job workerをなるべく安全に停止する - 酒日記 はてな支店
TheSchwartz の worker はシグナルに対してデフォルトでは何もしないので、再起動させようと SIGHUP を送信したりすると job 処理の途中で割り込まれて死ぬ可能性があります。 自前でトラップして安全に再起動する方法は過去に TheSchwartz の worker を安全に停止する で書きました。3年前の記事ですが。 今回は、シグナルへの対処がなされていない古いスクリプトを修正したものの、既に動いている worker を安全に止めないと入れ替えられないのでどうするか、というお話。 安全な停止法を twitter で緩募したところ、以下のようなアドバイスを頂きました。しかし別の queue DB 使うのは確実そうだけどちょっと面倒ですよね…… 緩募: signal trapしてないTheSchwartzのjob workerを安全に止める方法 2011-04-25 11
nginxでX-Accel-Redirectを使う場合に余計なヘッダを削除する - 酒日記 はてな支店
アプリケーションで認証後 S3 のコンテンツを返したかったのだけど、nginx で BASIC 認証を掛けていたらうまくいかなかった、というお話。 Amazon S3 の認証トークン付き URL をアプリケーションで生成し X-Accel-Redirect ヘッダに出力 nginx が S3 から取得してきてクライアントに返す という動作をさせたくて、以下のように設定。 # nginx.conf location = /reproxy { internal; set $reproxy $upstream_http_x_reproxy_url; proxy_pass $reproxy; proxy_hide_header Content-Type; }アプリケーションからは以下のようなレスポンスヘッダを出力。 X-Accel-Redirect: /reproxy X-Reproxy-URL:
標準出力や標準エラー出力を捕まえてテストする Test::Output / Capture::Tiny - 酒日記 はてな支店
Perl で、あるコードが標準エラー出力に吐き出した内容をテストしたい場面がありました。 自分でまず思いついたのは STDERR を dup して保存しておいて、ファイルにリダイレクトして、元に戻して、というやりかた。これはこれで動くのですが面倒。こういう場合は Test::Output (や miyagawa さんに教えてもらった Capture::Tiny) が便利です。 Test::Output はこんな感じ。 std(out|err)_(is|isnt|like) といったテスト関数が使えるようになります。 use Test::Output; use Test::More; stderr_is { # STDERR になにか出力するコード } "STDERRの内容", "description"; stdout_like { # code } qr/regexp/, "descri
mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店
Google の Page Speed の Apache module 版 mod_pagespeed をインストールして、ちょっとだけ動きを見てみた。 インストールは Ubuntu に deb パッケージで。 $ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb # sudo dpkg -i mod-pagespeed-beta_current_amd64.debconfig はデフォルトで入るものそのまま。 <IfModule pagespeed_module> SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER ModPagespeed on ModPagespeedUrlPrefix "http://localhost/mod_p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
