お探しのものを見つけるために、以下の項目を試してみてください。 キーワード検索のスペルを確認してください。 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。 新しい検索を開始してください。
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
この記事には、Microsoft Office Access データベースのパフォーマンスを向上させるヒントが含まれています。 これらのヒントに従うことで、レポートの実行や複雑なクエリに基づくフォームの開き方など、多くのデータベース操作の高速化に役立ちます。 データベースのパフォーマンスを向上させる最良の方法の 1 つは、一般的に使用されるフィールドのインデックスを作成することです。 インデックスを作成することで、この記事のヒントを使用して、パフォーマンスを向上させることができます。 Access によってインデックスが自動的に作成されますが、追加のインデックスによってパフォーマンスが向上するかどうかを慎重に検討する必要があります。 この記事では、インデックスの作成など、特定のデータベース オブジェクトのパフォーマンスを最適化する方法については説明しません。 詳細については、「 インデック
Google、IBMらがオープンソースの「Istio」公開。マイクロサービスのためのネットワーク機能「サービスメッシュ」を提供。Kubernetes対応 クラウド時代のアプリケーションは、サービスを提供するコンポーネントのような小さなソフトウェアが多数連係する、いわゆる「マイクロサービス」と呼ばれるアーキテクチャを備えたものになると考えられています。 このマイクロサービスアーキテクチャを備えたアプリケーションの内部では、各サービス間をつなぐためのネットワークがまるで網の目のように張り巡らせられ、そこでさまざまなトラフィックが発生していきます。 そしてこのネットワークを安定的かつ効率的でセキュアに運用することはマイクロサービスの運用に欠かせない基盤であり、そのためにはトラフィックのルーティングルールの設定、トラフィックが偏らないようにロードバランスの実現、セキュリティのための暗号化通信や認証
負荷テストをはじめるためには、目的、つまり性能要件を明確にしておく必要があります。 ありがちなのは、「100人が同時アクセスしても大丈夫なこと」というような安直な要件をたててしまうことです。 性能の指標はスループットや平均応答速度なので、性能要件で定義される「性能」についてもスループットや平均応答速度で定義される必要があります。 たとえば、 この記事では、どのように要件を整理していったらいいかをまとめます。 想定シナリオの確認 想定するシナリオを確認します。トップページのみアクセスされるシステムと、商品購入するシステムではユーザの動きが大きくことなります。 次のようなシナリオを想定していると仮定して話を進めます。 トップページ 商品詳細 カートへ入れる 購入手続き 購入確認 購入完了 この場合の、一人当たりのページビューは6PVです。 同時の定義を確認 「100人が同時」とは何でしょうか?
負荷試験の中で、最も利用頻度が高いのは「性能評価」ではないでしょうか。 性能評価を行うためには、次のことが重要になります。 見るべき指標 スループットと平均応答速度の評価方法 性能の定義方法 それぞれについて詳細をまとめていきます。 見るべき指標 性能評価の負荷テストで見るべき指標は、 スループット(pv/s) 平均応答速度 の2つになります。 スループットは、秒間あたりのアクセス数 スループットとは、秒間あたりのアクセス数を表します。単位は「pv/s」となります。pvとはページビューを表します。sは秒になります。 単位が、req/s(リクエスト/秒)ではなく、pv/s(ページビュー/秒)なところに注意が必要です。 システムの処理を受け持つサーバとしては、処理の最小単位はページビューではなく、リクエストになります。たとえば、トップページ(index.php)へアクセスしたとき、ユーザは1回
一行で説明 Apache JMeter について基本をおさらいします。 Apache JMeter とは Apache JMeter はベンチマークツールではなく、ユーザのシナリオに沿ってリクエストを投げ、そのレスポンスを測定するツール。 ベンチマークを取るためにも使うことは可能。 スレッド 一つのスレッドは一人のユーザを表す。一つのテスト計画に複数のスレッドを登録することが可能。複数スレッドを登録して実行するとすべてのスレッドが実行される。特定のスレッドのみを実行したい場合は、他のスレッドを無効化する必要がある。 スレッド数 シナリオ上の想定ユーザ数。 Delay Thread creation until needed このオプションを付けると、スレッドが必要になったときに立てられる。その為、負荷をかける側の負担を軽くすることが可能。 Ramp-Up期間 指定した数のスレッドをすべて立
最近JMeterを使ってて気になった部分をメモ。 JMeterはJava製のWeb向け負荷テストツール。この手のフリーなツールとしては代表的なもので、日本語での解説も多い。 JMeter(高機能/フリーなテストツール)第1回:JMeterの基本 -Java Apache/Jakarta Project- TECHSCORE 一方で、そのビミョーにクセのあるSwingベースのGUIにはいつもながら閉口するが、今回取り上げるのは、下に示したテスト結果のファイル保存オプションに出てくる設定項目の"Elapsed time"と"Latency"の違いについて。 テスト結果のファイル保存設定画面(jakarta.apache.orgより) 日本語にすると、"Elapsed time"は「経過時間」、"Latency"は「遅延」とあまり違いが分からない。この辺の解説を探してみたが、結局はjakarta
Not your computer? Use a private browsing window to sign in. Learn more
SQL Server には SQLIOSIM というストレステストを実施するためのツールが提供されています。 SQLIOSim ユーティリティを使用して、ディスク サブシステム上の SQL Server アクティビティをシミュレートする方法 このツールは SQL Server をインストールしなくても SQL Server と同等の I/O パターンをシミュレートしてストレージに対して負荷をかけることができるツールとなっています。SQL Server 2005 までは別途ダウンロードする必要があったのですが、SQL Server 2008 以降はインスタンスのディレクトリに標準で含まれるようなりました。 ただし標準で含まれている SQLIOSIM のコンポーネントには、サンプルの構成ファイル群 (sqliosim.cfg.zip) が含まれていませんので、これらのファイルが使用したい場合に
Microsoft Azure Universal Storage for SQL Server 2014で、どのストレージを使用すべきなのかを考察した結果が投稿されていたので概要を紹介する。 ストレージの種類 Azure仮想マシン内で、SQL Serverを使用するときに設定するストレージとして、三種類のストレージ(Azure File、Azure Disks、Azure Blob)が候補にあがる。 では、どのストレージを使用すべきなのかを検討した結果が、元記事のお話。 結論 大きなストレージのIOPSが必要なら、Azure Data Disk。 もっとファイル容量が必要なら、Azure Blob。 AlwaysOn Availability Groupやアプリケーションがトラフィックを必要とするようなネットワーク帯域が重要な場合は、Azure FileかAzure Blob。 SQL
以前、SQLIOSIM を使用したストレステストの実施 という投稿を書きました。 SQL Server の IO パターンをテストするツールとして SQLIO Disk Subsystem Benchmark Tool (SQLIO) というツールもあります。 このツールを使用してディスク I/O のベンチマークを実施するための方法を軽くまとめてみたいと思います。 SQLIO, PowerShell and storage performance: measuring IOPs, throughput and latency for both local disks and SMB file shares もとても参考になりますのでこちらも一読してみるとよいかと。 ■ツールの実行方法 SQLIOSIM は GUI から実行することができましたが SQLIO は CUI のみのツールとなって
Automatic Storage Management(以後ASM)を用いてStorage GRID環境を構築する際、「どういう構成がいいのかな?」という問いにお答えする設計の勘所を紹介します。 サーバ機の選び方 CPU 特に指定なし。ただしStorage GRIDをデータベース用途でかつDWHに使用する場合は後述の1コアあたりが引き出せるI/O帯域について考慮しておく。 メモリ ASMが含まれるGrid Infrastructureのみをインストールする場合は最低1.5GByte。 Oracle Databaseもインストールする場合は最低2.5GByte。 ただしメモリはもちろん多めに搭載が理想的。 4GByte DIMMと8GByte DIMMを比較した場合、4GByte DIMMの方が容量あたりの価格が安価。したがってメモリ総量72GByte程度まででよければ、DIMMを大量にイ
いいものを見つけたのでコピペ。 yes >> /dev/null & 最後に & お勧め w(二つターミナルが必要でなくなる。) ちなみに メモリ負荷をあげる魔法のコマンド /dev/null < $(yes) & LinuxでCPU負荷を上げる魔法のコマンド - Qiita ">>" は ">" でも良いと思うが、何か特別な理由があって">>"にしているのだろうか。 追記(2014/10/08): ただのメモにはてブがたくさん(当社比)ついてビックリ(^-^; コア数に対する考慮が足りない。 コア数に対する考慮が足りない。 - gomakyuのコメント / はてなブックマーク とコメントを頂いた通り、上記のコマンドを実行しても1つの論理CPUを使い切るだけです。 例えば上の図の通り、1ソケット * 4コア * 2スレッド で論理CPU数が8の場合は、ざっくり、1多重で実行すると12.5%
ピーク時になると応答時間が急激に悪化したので、とりあえずCPUとメモリを倍増しておけば大丈夫かな……と勘に頼って対応し、ドツボにはまった経験、ありませんか? この連載では、インフラエンジニアなら最低限理解しておきたい性能問題の基礎を解説します。(編集部) はじめに 第3回「遅いところを直すだけでいいのですか?」までは、性能の基礎の中でも特に基礎的な話をしてきました。第3回は多少はリアリティのある話題だったと思いますが、内容的には数学の勉強のような話が中心で、現実のITシステムでの性能対策に使うレベルにはほど遠いものでした。 今回から始まる後半からは、実際に活用できる性能対策の話をしていきます。今回は、性能対策用の専用ツールを使わずに、机上での試算でどこまで性能改善をシミュレーションできるかを示したいと思います。設定した問題のケースでは、解説のために単純化した部分がいくつかありますが、現実問
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く