タグ

ブックマーク / dsas.blog.klab.org (20)

  • 「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋

    「推測するな計測せよ」という格言がよく知られています。この格言は(ISUCONに優勝した)Goの作者の一人でもある、 Rob Pike 氏の言葉が元になっています。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 UNIX哲学 on Wikipedia このルールは、推測だけで高速化のための変更をすることを諌めていますが、直接に高速化の効果が無い変更をするなとは言っていません。 正しいデータ構造やアーキテクチャは、それだけでは性能が向上せず、それを利用した改善を入れて初めて効果が

    「推測するな計測せよ」は「性能上がらなかったら捨てろ」ではない : DSAS開発者の部屋
  • Serfの障害検知とメンバシップ管理について : DSAS開発者の部屋

    はじめに KLabさんの協力会社として一緒にお仕事をさせて頂いておりますクラスターコンピューティングと申します。今回Serfという面白そうなツールがあるので試してみました。 システムの高可用性化を目的にクラスタを構成することはよく行われていると思います。可用性を維持するために大切なことはクラスタに属するサーバの状態を常に把握しておくことです。そしてサーバの状態に変化が生じた場合ーたとえばサーバが不意に停止した場合ーそれに応じて適切な動作ができるようにする必要があります。システムのサービスはこの土台となるサーバ管理の仕組みの上に構築されます。 Serfはこのクラスタの土台となるサーバの管理の部分をサポートしてくれるツールです。Serfはゴシッププロトコルを利用したP2P型のクラスタを構成します。これによりシンプルな作りでかつ信頼性やスケーラビリティに優れ、そしてネットワーク的な効率も良い管理

    Serfの障害検知とメンバシップ管理について : DSAS開発者の部屋
  • ISUCON6予選をトップ通過しました : DSAS開発者の部屋

    @methane です。「この技術部には問題がある!」というチーム名で @kizkoh (インフラ担当), @mecha_g3 (アプリ担当) とともに ISUCON 6 に参戦し、予選をトップスコアで通過しました。 恒例のふりかえり記事を書きます。 ふりかえり 残念ながらスコアは記録してないのですが、時系列順にやったことをまとめます。 アプリのコードは methane/isu6q-app で公開しているので、興味がある方はコードを確認してください。 strings.Replacer を使う 使用言語は最初から Go と決めていたのですが、Goの初期実装は遅すぎてタイムアウトで最初からスコア無しでした。 top でアプリのCPUが支配的なのはすぐ判りましたし、コードを読めばなにが遅いのかも一発で判りました。そんなに長くないので関数全体を張ります。 func htmlify(w http.R

    ISUCON6予選をトップ通過しました : DSAS開発者の部屋
  • Tomoru と Pochiru と Linking : DSAS開発者の部屋

    Braveridge 社はその後も活発に Linking 対応製品をリリースしています。最近目にとまった「Pochiru」というデバイスを買ってみました。Pochiru には LED に加えネーミングどおり押しボタンが実装されています。そのため通信先の機器との双方向のやりとりが可能です。 ボタンものの BLE デバイスはいろいろ販売されていますが、リモートシャッターやメディアプレイヤーの操作といった所定の目的に閉じたものが多く、廉価でありながら自作のアプリケーションと汎用的に連携可能であることが Pochiru の魅力です。この価格でこのサイズの BLE ボタンデバイスを自作することの難度を考えるとコストパフォーマンスの高い製品と言えるでしょう。 プログラムを書く Tomoru や Pochiru のような Linking 対応デバイス用のアプリは Project Linking が無償で

    Tomoru と Pochiru と Linking : DSAS開発者の部屋
  • pixiv private isucon 2016 攻略 (2/5) : DSAS開発者の部屋

    攻略記事一覧: pixiv private isucon 2016 攻略 (1/5) pixiv private isucon 2016 攻略 (2/5) pixiv private isucon 2016 攻略 (3/5) pixiv private isucon 2016 攻略 (4/5) pixiv private isucon 2016 攻略 (5/5) アプリを読む ソースコードを読みながらだいたいの構成を把握していきます。 フレームワークは goji を使っている。 goji のサイトを見ると同じ名前で新しいフレームワークを作り直したみたいだけど、これは古い方を使ってるみたいです。 セッションは Gorilla のライブラリに memcached store を組み合わせている テンプレートをレンダリングのたびにコンパイルしてるのが重そう。 コメントのユーザーをいちいちユーザー

    pixiv private isucon 2016 攻略 (2/5) : DSAS開発者の部屋
  • pixiv private isucon 2016 攻略 (1/5) : DSAS開発者の部屋

    攻略記事一覧: pixiv private isucon 2016 攻略 (1/5) pixiv private isucon 2016 攻略 (2/5) pixiv private isucon 2016 攻略 (3/5) pixiv private isucon 2016 攻略 (4/5) pixiv private isucon 2016 攻略 (5/5) pixiv さんが社内で開催したプライベート ISUCON の AMI を公開してくれたので、手順を残しながら攻略していきます。 ISUCON6出題チームが社内ISUCONを開催!AMIも公開!! リポジトリ この記事の対象読者は途中で何をすればいいかわからなくなってしまう ISUCON 初心者です。 Go を利用して攻略していきますが、他の言語で参加する場合でも考え方などは参考になると思います。 最低限の初期設定 ssh の公開

    pixiv private isucon 2016 攻略 (1/5) : DSAS開発者の部屋
  • クエリキャッシュは切ったほうがいいんじゃなイカ? : DSAS開発者の部屋

    KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって

    クエリキャッシュは切ったほうがいいんじゃなイカ? : DSAS開発者の部屋
  • 「パスワードの管理を避ける」という考え方 : DSAS開発者の部屋

    手持ちのアカウントが増えてくるとパスワードの管理方法が考えどころとなります。このところメジャーなネットサービスへの不正ログインやアカウントの悪用が相次いで報じられていることもあり パスワード管理の重要性は「古くて新しい問題」としてあらためて広い層に浸透しつつあります。 その一方でパスワードをきっちり管理することは必ずしも簡単ではありません。平易な内容だと第三者によって類推・導出されるリスクが大きいものの複雑にすると覚えにくい。だからと言って複数のサービスで同じものを使いまわすとそれが漏洩した場合に一斉に攻撃を受ける危険がある。結局、安全度の高いパスワードをサービスごとに使い分けることは人間の記憶だけでは困難なので何らかの外部記憶を利用することになります。ただし、それが何らかのデバイスであれコンピュータデータの形式であれ、情報としてそこへ保存した時点で盗難・流出の可能性はゼロではなくなります

    「パスワードの管理を避ける」という考え方 : DSAS開発者の部屋
  • TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋

    昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日海外の間を結ぶ長距離ネットワーク(いわゆるLong Fat pipe Network)において、通信時間を削減するにはどうしたらいいか?」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間(伝送遅延)を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日国内のホスト同士であれば、RTT(往復遅延時間)はだいたい10〜30ms程度ですが、日・北米間だと10

    TCP高速化プロキシ「AccelTCP」を公開しました : DSAS開発者の部屋
  • gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋

    ネイティブアプリの開発とかしてると、ついつい git にスプライトの png とか一緒にコミットしてしまって、気づいたらリポジトリサイズが 1GB 超えてたとかありますよね。 git annex とか、格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。 そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。 git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル体から

    gitでバイナリファイルを気軽に扱えるフィルターを作りました : DSAS開発者の部屋
  • WebSocket アプリの負荷分散 : DSAS開発者の部屋

    最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo

    WebSocket アプリの負荷分散 : DSAS開発者の部屋
  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • ログからは見えてこない高負荷サイトのボトルネック : DSAS開発者の部屋

    ちょうど1年前に「高負荷サイトのボトルネックを見つけるには」という記事を掲載していますが、この手のトラブルシューティングって結構大変で悩ましいですよね。はじめまして、新入りの@pandax381です。 ログからは見えてこないもの 「サイトの応答が遅い」という問題が発生した場合、その原因はどこにあるでしょうか。 Webアプリケーションの処理に時間が掛かっている DBサーバに投げたクエリーの応答が遅い サーバの処理能力を超えている などなど、いくつもの可能性があります。通常、上に挙げているような問題は、アプリケーションやサーバのログを調査することで、原因を突き止めることができます。 一方で、こういったログの調査だけでは、その原因にたどり着くことができなかったり、相当な苦労が伴うケースもあります。 あるサイトのある日の出来事 つい先日のことですが、KLabの運営している某ソーシャルゲームにて、サ

    ログからは見えてこない高負荷サイトのボトルネック : DSAS開発者の部屋
  • DSAS開発者の部屋:Android アプリケーションが起動するまでの流れ

    プログラム開発のために Android 上でアプリが起動するまでの過程を調べてみました。備忘をかねて、ソースコードをひと通り追跡した記録をここに控えます。 まとめ ※クリックすると大きな図が開きます Zygote(ザイゴート)プロセスは、Android システムブート時に起動し DalvikVM 体と Android プログラムの実行に必要なダイナミックリンクライブラリと Java のクラスライブラリをロードした状態で待機する常駐プロセスである Zygote プロセスの目的は、同プロセスを fork することによりプログラム実行用のプロセス環境を素早く効率的にシステムへ提供することにある UNIX ドメインソケット /dev/socket/zygote が Zygote プロセスへのインターフェイスであり、同ソケットにプロセス生成要求を送出すると Zygote はプロセス fork を実

    DSAS開発者の部屋:Android アプリケーションが起動するまでの流れ
  • Erlangとは何だったのか : DSAS開発者の部屋

    タイトルは釣りです。 methane です。 8/20(土)にLL Planetesに行ってきました。 今年は JavaScript 一色と言っていいほど、 JavaScript の存在が大きくなっており、 そのなかでも特に Node.js の話題が多かったように思います。 「Node.jsとはなんだったのか」というセッションでは主にコールバックチェーン型プログラミング vs 軽量スレッドを使った手続き型プログラミングの話題や各言語におけるライブラリなどが 紹介されていたのですが、以前個人的な興味でいくつかの言語とライブラリで echo server を実装していたので、他にも興味を持っておられる方のために公開します。 いろんな言語でEcho Server@github 参考に、簡単なベンチマーク結果も載せておきます。各言語・フレームワークで完全に同じものを 実装しているわけではないし、エ

    Erlangとは何だったのか : DSAS開発者の部屋
  • チューニンガソンで優勝してきました : DSAS開発者の部屋

    7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、 ab を使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用

    チューニンガソンで優勝してきました : DSAS開発者の部屋
  • 高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋

    はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか? 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の2倍や3倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立

    高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
  • 負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋

    負荷試験ツール インターネット破壊を公開しました。 こちらはずっと社内で負荷試験に使用していたツールです。社内で使用していたものなので、ソーシャルアプリ向けの機能などが多少追加されていますが、もちろんんそれ以外のWebアプリケーションでも使用できます。 基的にはApache JMeterのようなWebアプリケーションむけのシナリオ負荷試験ツールです。コマンドラインオペレーションだけで実行でき、サーバー上で簡単に負荷試験を実施できるのが特徴です。POSTリクエストなどはもちろん、レスポンスのチェックやUserAgentの偽装、ランダムな値をパラメーターにセットする機能も実装しています。 注意: 当然ながら自分の管理下にないサイトに向けて負荷試験ツールを実行するのは絶対にやめてください。非常に危険です。 物騒な名前がついていますが、これは完全にわたしの小児的感性の趣味によるところです。地震で

    負荷試験ツール「インターネット破壊」を公開しました : DSAS開発者の部屋
  • 並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋

    並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント こんにちは、takada-at です。 Rubyのイベント駆動型ネットワークプログラミングフレームワーク Rev と EventMachine で HTTPクライアントを動かしてみました。 イベント駆動型ネットワークプログラミングフレームワークとは何か説明しだすと難しいですが、一言で言うと、以下のようになります。 # ふつうのフロー駆動型プログラム Net::HTTP.start(host, port){|http| res = http.get(path) #この処理が終わってから } puts "done" #この次の処理が実行される # イベント駆動型プログラム client = Rev::HttpClient::connect(host, port

    並列1000コネクションに耐える! Ruby のイベント駆動ライブラリ Rev と EventMachine の HTTPクライアント : DSAS開発者の部屋
  • Apache 2.3/2.4系の新機能を見てみよう その3 〜MPMの動的ロード〜 : DSAS開発者の部屋

    Apache 2.3の特長を探る さて、Apache 2.3探索シリーズの第3回になります今回、MPM(Multi-Processing Modules)に話題を移します。 従来Apache 2.0/2.2ではMPMはconfigureでのオプション指定によって選択し、ビルドでスタティックリンクされます。そのため、もしMPMを変える場合はconfigureでの指定を変えてビルドする所からやり直しになります。2.3/2.4からはこれがApacheモジュールと同じようにLoadModuleディレクティブで実行時に選ぶことができるようになるそうです。 この仕組みを利用する為には、前回のビルドでのconfigureオプションに項目を1つ追加する必要があります。--enable-mpms-sharedオプションを追加し、引数にallを与えてもう一度ビルド&インストールしてみましょう。 $ confi

    Apache 2.3/2.4系の新機能を見てみよう その3 〜MPMの動的ロード〜 : DSAS開発者の部屋
  • 1