negima1976のブックマーク - はてなブックマーク

AWS X-Ray による ISUCON8 本選問題の解析 - 酒日記はてな支店

ISUCON8 の本選問題は、競技者がコントロールできない外部 API 呼び出しを多数含んだ出題内容でした。講評では、サービスの特性を適切に分析した上で、まとめるところはまとめたり、遅延させるところは遅延させるなど ……とさらっと書かれていますが、実際そんなことを短時間で分析することは可能なのかよ！という話題が競技後の懇親会でもあったので、それ AWS X-Ray でできるよ、というエントリをまとめておきたいと思います。今回の解析は Perl 版の初期実装に対して行ったものですが、なぜ Perl かというと AWS の公式 SDK にない X-Ray 関連の CPAN モジュールを自分が書いているので、その宣伝も兼ねています。(blogエントリ書いてなかった) AWS::XRay Plack::Middleware::XRay Devel::KYTProf::Logger::XRay

negima1976 2018/10/29

リンク

ISUCON8 本選出題記あるいはISUCONベンチマーカー負荷調整の歴史 - 酒日記はてな支店

ISUCON 8 の本選出題を同僚の @ken39arg と担当しました。参加された皆様、運営にご協力して頂いたすべての関係者の方々にお礼申し上げます。恒例の #isucon pic.twitter.com/iXAjgfgbeZ— fujiwara (@fujiwara) 2018年10月20日問題についての講評は公式の ISUCON8 本選問題の解説と講評をご覧頂くとして、こちらでは今回、出題に導入された新要素である「シェア機能」について、どういう経緯で導入されたのか、裏話的なことを書いておきたいと思います。「ベンチマークの負荷を自分で決めるのも、自動で際限なく負荷が上昇するのも実際のアプリケーションとは違うよね?」というところから思いついた機構なのですが、経緯についてはいろいろな前提と、歴史の理解が必要になります。結果的に長文になってしまいました。 ISUCONベンチマーカーと

negima1976 2018/10/25

リンク

nginx実践入門 - 酒日記はてな支店

「nginx実践入門」を著者の @cubicdaiya さんからいただきました。ありがとうございます。簡単ですが感想など。 nginx実践入門 (WEB+DB PRESS plus) 作者: 久保達彦,道井俊介出版社/メーカー: 技術評論社発売日: 2016/01/16メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る感想一通り読んだ感想としては、本書は「『実践』入門」であっていわゆる入門書ではないのですね。手取り足取りしてくれるわけではなく、リファレンスの詳解でもなく、あくまで実践的に運用する人へ向けての、実用的な使い方の入り口を紹介してくれる本でした。特に最近重要性の高い TLS(SSL) での安全でハイパフォーマンスな設定、大規模コンテンツ配信サーバの構築を例とした多段 proxy 構成、実用的なログ出力と Fluentd によるメトリクスモニタリン

negima1976 2016/01/26

nginx

リンク

ISUCON5予選を全体1位で通過しました - 酒日記はてな支店

ISUCON5 の予選1日目にチーム「fujiwara組」(@fujiwara, @songmu, @sugyan) として参加して、全体通して1位のスコアで通過しました。 isucon.net 今回は ISUCON 1 の時の優勝チームを再結成という形になったわけですが、最初はISUCON 4の時と同じ社内のチームででようかと思ってたんですよね。ところが昨年優勝チームだった「LINE選抜生ハム原木」が今回参戦できないということで、sugyanがチームどうしよう、と困っていたのでつい…*1 初代fujiwara組を再結成しよう— fujiwara (@fujiwara) 2015, 5月 27 準備今回はOSは Ubuntu(バージョン非公開)なのが事前にレギュレーションで公開されていたので(前年まではCentOS, Amazon LinuxなどのRedHat系ディストリビューションで

negima1976 2015/09/28

リンク

#isucon ではどんなことを考えながら作業していたか - 酒日記はてな支店

前のエントリ #isucon で優勝してきましたは当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえこのクエリは実行に 300〜400 ms 程度かかるアプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、

negima1976 2011/08/29

isucon

リンク

#isucon で優勝してきました - 酒日記はてな支店

なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧くださいおそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記はてな支店自分でももう少し詳しく振り返りエントリ書きました。まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host