様々なrate limitアルゴリズム - Carpe Diem
概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、本来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする（＝上限を設定する）アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token
あるSPソーシャルゲームのチューニングメモ - Qiita
WEBサーバが通常40台でGvGバトル時は60台に増やすというスケール設定になっている。 CPUもメモリも使用率高くないのにサーバ台数増やさないとレスポンスが悪くなる。 WEBサーバ：CPU10%ぐらい、メモリ10%ぐらい DBサーバ：CPU10~20%ぐらい、メモリ20%ぐらい これ以上サーバを増やしたくないし、できれば減らしたい。 調査で使うもの New Relic https://newrelic.com/ これをWEBサーバのどれか1台にインストールしておきます。 最初の30日は有料版の機能も使えるのでその期間で一気にボトルネックを探りました。 URLごとにどんなメソッドやSQLが何回実行されているかなど見れるのでチューニングが捗ります。 無料で使える機能だけでも割と使えます。 アラート閾値（初期値）が少し高めなのでチューニング中は低く設定しましょう。 そうしないと重い箇所を特定で
モバイルWebパフォーマンスの現在と未来
iOSアプリケーション開発会社の経営者であるDrew Crawford氏は、現在のモバイルWebアプリケーションが遅く、また、近い将来にその遅さが大幅に改善されると思えない理由を、ブログ記事（内容が充実しており、良く調査して書かれている）の中で明らかにした。 このブログ記事は、これより前に書かれた記事への追加記事である。前の記事で氏は、モバイルにおけるJavaScriptのパフォーマンスがデスクトップの10倍遅いことを指摘した。その記事は激しい批判を浴びたため、Drew氏はそれに答える形で、さらに詳細な内容の記事を記した。モバイルの貧弱なパフォーマンスと、それについての改善が見られない理由は、次の3つに分類される。 モバイルのARMプロセッサのスピードと、デスクトップのx86プロセッサのスピードとの違い JavaScriptエンジンのパフォーマンスの傾向 ガベージコレクションに関連する特定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Which are faster? | Computer Language Benchmarks Game
