更新頻度の多いデータのキャッシュ : DSAS開発者の部屋
@methane です。 ISUCON 7 本戦で最大のスコアアップできたポイントが、 status と呼ばれる重い計算の結果となるJSONのキャッシュでした。 近年のISUCONによくある、「更新が成功したら以降のレスポンスにはその更新が反映される必要がある」（以降は「即時反映」と呼びます）タイプの問題だったのですが、今回のように更新頻度の高くかつ即時反映が求められるデータをキャッシュする方法について、より一般的に解説しておきたいと思います。 即時反映が不要な場合 まずは基本として、即時反映が不要な場合のキャッシュ方法からおさらいします。この場合、一番良く使われるのは参照時に計算した結果を Memcached などにキャッシュし、時間で expire する方法です。 このタイプのキャッシュには、参照元が分散している場合（Webサーバーが複数台あるなど）に Thundering Herd
Re: Configuring sql.DB for Better Performance : DSAS開発者の部屋
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
LVSの高負荷対策 その2 ~障害の再現とその原因~ : DSAS開発者の部屋
こんにちは。インフラ担当の岡村です。 「LVSの高負荷対策 その1 ~障害発生~」の記事で、大量のSYNパケットを受信した際にロードバランサの再起動が発生したことと、その緊急の対策についてご紹介しました。 今回は、再現確認を行い判明した再起動の原因と、LVSに備わっている高負荷対策の機能についてご紹介します。 検証 前回ご紹介した通り、障害発生時のログからメモリ周りが怪しそうでした。 そこで、ロードバランサにSYNパケットを送り、メモリの使用量の推移を観察しながら、再起動が発生するかどうかを確認しました。 検証環境の構成は次のようになります。 検証環境の構成 パケット送信用サーバを複数台、ロードバランサを1台、Webサーバを1台使用し検証を行いました。 ロードバランサの検証を行う上で、本番環境と同様にロードバランスの処理をさせたかったため、LVSに振り分け先のWebサーバのIPアドレスを複
リアルタイム通信環境の(一部)構成紹介 : DSAS開発者の部屋
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
Dropbox アカウントひとつで利用できるプッシュ通知機構 : DSAS開発者の部屋
2018年6月追記： Dropbox API の仕様変更により以下の内容はすでに obsolete です。記事は残しますが、過去の情報であることをご了承下さい。 Dropbox 社は広く知られるファイル系のサービスとは別に 2013年より非ファイル形式の構造化データの保存・読み出しに対応するデータストアサービスを公開しており、Dropbox アカウントを持っていれば Dropbox Datastore API 経由でこのサービスを利用できます。同 API は全体的にシンプルで SDK のサポート範囲も広いため自作のソフトウェアへ手軽に組み込むことが可能です。 自前でサーバ環境を構築・運用する手間なしにレコードイメージのデータをネットワークストレージ上で取り回せるのは便利で、また多くの人がアカウントを持っていることへの安心感もあり、この Dropbox のデータストアサービスはさまざまな用途
[補足記事]ディレクティブ処理関数登録マクロ一覧 (apache module 開発事初め その3-2) : DSAS開発者の部屋
AP_INIT_XXX("directive", function, info, where, help) 引数の意味はそれぞれ directive設定ファイル中で用いるディレクティブの名前．char *型．大文字小文字は無視されます． functionディレクティブ処理用の関数を指定すします．関数の型は，AP_INIT_XXX の種類によって変わります． infofunction() を呼び出す時に渡す情報．void *型．特に渡すものがなければ NULL を指定します． whereこのディレクティブが現れてよい場所の指定．int型．指定できる値のようなものがあります． OR_LIMIThttpd.conf内の <Directory> か <Location> の中か， AllowOverride Limit が指定されていれば .htaccess の中．このタイプのディレクティブの例と
DSAS開発者の部屋:Twisted vs Tornado vs Go で非同期Webサーバー対決
Goのランタイムのバグを踏んで解決しました。解決までの過程を記事にします。 同じようなランタイムのバグを踏んで、小さい再現コードを作れない場合の参考にしてください。 自分のプログラムを疑う あるSlackチャンネルで Go で書かれたサーバーのクラッシュが話題になっているのを見つけました。その時に共有してもらったトレースバックです。 runtime: pointer 0xc007b8af97 to unused region of span span.base()=0xc004000000 span.limit=0xc004002000 span.state=1 fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?) runtime stack: runtime.throw(0xc046ca,
こんなに簡単！ Linuxでロードバランサ (2) : DSAS開発者の部屋
前回までで、 複数のWebサーバにロードバランスする というところまではできました。 これでリアルサーバへ負荷分散することができたのですが、冗長性がありませんでした。つまり、リアルサーバがダウンしても、ロードバランサはそれを認識できず、ダウンしているリアルサーバなのにパケットを送ってしまっていました。 このとき、クライアントから見ると、たまにサーバから応答がないように見えてしまいます。 というわけで今回は冗長化のお話、 リアルサーバのヘルスチェック を紹介したいと思います。 今回はkeepalivedを使います。 おおざっぱにいうと、keepalivedは2つの機能を提供します。 1. ヘルスチェック機構と連携したIPVSでのリアルサーバの管理 (--check) 前回ipvsadmコマンドを使って行ったような、バーチャルIPアドレス (VIP) やリアルサーバの管理を設定ファイルに記述す
Pythonの内包表記はなぜ速い？ : DSAS開発者の部屋
「エキスパートPythonプログラミング」の発売が、Amazonや一部の書店で始まりました。 エキスパートPythonプログラミング 著者：Tarek Ziade 販売元：アスキー・メディアワークス 発売日：2010-05-28 クチコミを見る 今回は、「エキスパートPythonプログラミング」の2章から、リスト内包表記について補足します。 本書で、リスト内方表記が速い理由について、次のような訳注を書きました。 訳注：リストに要素を append() する場合、インタプリタは「リストから append 属性を取り出してそれを関数として呼び出す」という処理をしなければなりません。 それに対して、リスト内包表記を使うと、インタプリタに直接「リストに要素を追加する」という処理をさせることができます。インタプリタが解釈する命令数が減る、属性の取り出しが不要になる、関数呼び出しが不要になる、という3
apache module 開発事始め : DSAS開発者の部屋
先日は，必要に迫られて Apache 1.3 の mod_access を改造したという話を書きました．その時は単にあるものを改造しただけでしたが，ふと思い立って，一から Apache 2.0 用のモジュールを書いてみました．書く上で色々 Web サイトを探してみたのですが，あまり日本語の入門向けの文章が見あたらなかったので，開発する上で分かったこと(と言うほど大したものじゃないですが)をまとめておこうと思います． フェーズには，例えばそのリクエストを受け付けるか拒否するかを決めるフェーズや，リクエストされた URI と実際のディスク上のファイルとの間の対応付けを解決するフェーズ，そしてもちろん実際のレスポンスを生成するフェーズ等があります．hook 関数を挿入するポイントはこれらのフェーズになりますが，もちろんその全てのフェーズのための関数を用意する必要はありません．また個別の設定を施す
クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
