3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
Phpconf2010
[CTO Night & Day 2019] グローバルのサービス展開に向けたマルチリージョンアーキテクチャ- #ctonightAmazon Web Services Japan
Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～
2010/07/14 リリース直後から大量のユーザーが流れ込み、高負荷に晒されるソーシャルアプリ。システムダウンによって、ビジネスチャンスを逃さないためには負荷対策が不可欠です。 KLabは長年の大規模・高負荷モバイルサイトの構築・運用によって、対負荷性能を持ったアプリ・インフラのノウハウを積み重ねてきました。ソーシャルアプリ市場においてはオープン当初からSAPとして参入し、ソーシャルアプリならではのアクセス集中を経験したことで、現在はより安定したサービスを提供できるに至っています。 今回は、KLabが実施してきたそんな負荷対策ノウハウを広く紹介いただきます。Read less
ソーシャルアプリセミナー「LAMPで作るソーシャルアプリの負荷対策」に参加してきました - gusagiの日記
株式会社コンテンツワンさん主催のソーシャルアプリセミナー「LAMPで作るソーシャルアプリの負荷対策 〜アプリとインフラの調和のテクニック〜」に参加してきました。講師は、KLab株式会社の森本さん。 全体的な内容としては、どのようにしてHTTP通信の待ち行列をなくすかという主旨で、ボトルネックとなりやすいDB側の改善と、Web（アプリ）側の改善のどちらについてもお話がありました。 DB側については、目新しく画期的な手法ではなく基本に忠実に対応を行っているようで、やはり土台となる知識と経験は重要と言うことを再認識。Web側はGDを自分たちでカスタマイズされているなど、ライブラリにまで踏み込んで負荷対策が必要な場合もあるということに驚きました。 自分自身への記録をかねて、セミナー中のメモ（メモ抜けや聞き間違いなども含まれている）を貼っておきます。 ---- 本論に入る前に 本発表はモバイルでのソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
