Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
概要 ※この記事は弊ブログ記事(はてな)、Kubernetesの負荷試験で絶対に担保したい13のチェックリストと同内容です ここ最近、Kubernetesクラスタを本番運用するにあたって負荷試験を行ってきました。 Kubernetesクラスタに乗せるアプリケーションの負荷試験は、通常の負荷試験でよく用いられる観点に加えて、クラスタ特有の観点も確認していく必要があります。 適切にクラスタやPodが設定されていない場合、意図しないダウンタイムが発生したり、想定する性能を出すことができません。 そこで私が設計した観点を、汎用的に様々なPJでも応用できるよう整理しました。 一定の負荷、スパイク的な負荷をかけつつ、主に下記の観点を重点的に記載します。 Podの性能 Podのスケーラビリティ クラスタのスケーラビリティ システムとしての可用性 本記事ではこれらの観点のチェックリスト的に使えるものとして
mod_proxy_balancer単体でstickysessionを設定 † mod_proxy_balancerのみでstickysessionを設定する方法について解説します。 いろいろ調べるといろいろなやり方がありそうですが、Webサーバのmod_proxy_balancerのみでstickysessionまで実現できたので、そのメモ書きです。 想定の構成は以下の通りです。 想定構成は、フロントにWEBサーバ1台、バックにAPサーバ2台です。 Webサーバは何台あっても、上位にロードバランサーがいれば設定は同一となります。 Webサーバ : mod_proxy_balancerの設定対象です。 APサーバ : mod_proxy_balancerにて振り分けする対象のAPサーバです。 セッション保持して、振り分けをする必要があるアプリケーションが動作することとします。 ↑ mod_
上記の広告は1ヶ月以上更新のないブログに表示されています。 新しい記事を書く事で広告が消せます。
はじめまして。プラットフォーム開発本部のせじまです。好きなものはDisk I/Oです。 今回はMySQL(on Linux)のレプリケーションにまつわる、ちょっとしたお話をさせていただきたいと思います。 はじめに MySQL4.0以降のレプリケーションは、 Masterのmysqldが、INSERT/UPDATE/DELETEなどの更新情報を、バイナリログに記録する。 Slaveのmysqld(IOスレッド)は、masterのmysqldに接続し、バイナリログを転送する。 Slaveのmysqld(IOスレッド)は、受信したバイナリログ内容を、リレーログに記録する。 Slaveのmysqld(SQLスレッド)は、リレーログを読み込み、更新内容をslaveのDBに反映する。 といった仕組みになっています。図にすると次の通りです(*1)。 MySQLのレプリケーションはとても良くできた仕組みな
By Ben Koski December 20, 2010 2:01 pm December 20, 2010 2:01 pm In the Times Interactive News Department, we pay careful attention to caching strategy to make sure it’s a good fit for the project at hand. Publishing live election results requires a carefully tuned system: the setup must be able to withstand some of the most intense traffic levels seen all year at NYTimes.com, but at the same time
HHVM is an open-source virtual machine designed for executing programs written in Hack and PHP 5 and 7. HHVM uses a just-in-time compilation approach to achieve superior performance while maintaining the flexibility and ease of use that PHP developers are accustomed to (dynamic features like eval(), rapid run-edit-debug cycle, etc). HHVM is used by Facebook to serve billions of web requests per da
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の2倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を1台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を2倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
What is Memcached? Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering. Memcached is simple yet powerful.
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
By Ilya Grigorik on February 11, 2008 If web architectures, performance, or scalability are topics you would like to keep on top of (who doesn't!), then chances are, you've heard of Nginx ("engine x"). Originally developed by Igor Sysoev for rambler.ru (second largest Russian web-site), it is a high-performance HTTP server / reverse proxy known for its stability, performance, and ease of use. The
Welcome to The Core Project - Tiny Core Linux The Core Project is a highly modular based system with community build extensions. It starts with a recent Linux kernel, vmlinuz, and our root filesystem and start-up scripts packaged with a basic set of kernel modules in core.gz. Core (17MB) is simply the kernel + core.gz - this is the foundation for user created desktops, servers, or appliances. Tiny
AsyncIOについて(その1)の続き. NONBlockでIO処理をする方法としてselectとシグナルを使う方法があるというのが前回の話だったが, selectはselectよりkqueue,epollで述べたとおり, ビジーループがかかるためあまり効率はよくなく,シグナル方式は制約があるためあまり使い勝手がよくない. というわけで新しく出てきたのがPOSIX Asynchronous I/O(AIO)という機構だ. これはIOのwaitをイベントドリブン形式にしてビジーループをなくそうというものだ. プログラムの流れとしては下記のようになる. 1. 対象となるファイルディスクリプタにシグナルハンドラもしくはイベントハンドラを登録しておく 2. aio_read/aio_writeを呼び出すと制御はすぐにユーザに戻る. 3.対象のファイルディスクリプタの処理が終わると登録されていたハン
最近のOSにはAsyncIO(AIO)という新しいI/Oの仕組みが導入されているようだ.lighttpdの次期バージョンではAIOを導入することで8割もパフォーマンスが上がったようで非常に興味深い. またあちこちのBlogを見る限りNonBlockingI/OやNonBlockingI/O+シグナルとAIOが混同されている気がしたので,それら整理してみたい. はじめに I/O処理であるシステムコールのread/writeは対象がディスクだったり,ソケットだったりデバイスだったりするわけだが,通常これらのIO処理はCPU処理やメモリ処理に比べ非常に遅いことが知られている. 通常readが行われるとreadが終わるまで,永遠に処理は戻ってこず,プロセス的には待ち状態になってしまう.これは「Blocking」と呼ばれる. 遅いディスクやデータがいつ来るかわからないソケットなどに対するIO処理では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く