パフォーマンス モニター (パフォーマンス カウンター) でWebサーバー(IIS)の負荷調査をする (IIS - Internet Information Service Tips)
パフォーマンス モニター (パフォーマンス カウンター)でWebサーバー(IIS)の負荷調査をする手順を紹介します。 この記事で紹介している測定は、Webサーバーの接続数やエラー発生などの指標を確認しています。Webサーバーの静的ファイル送信では、 CPU高負荷やレスポンスタイムの低下などのパフォーマンス低下は発生しにくいため、ボトルネックとなる個所を特定する場合は、Webサーバーのパフォーマンス測定ではなく、 ASP.NETアプリケーションなどのWebアプリケーションを調査するほうが問題の発見につながります。 ASP.NETアプリケーションのパフォーマンスを測定する方法はこちらの記事を参照してください。 パフォーマンス モニターの起動 パフォーマンスモニターを起動します。パフォーマンスモニターはスタートメニューの[管理ツール]フォルダ内の[パフォーマンス モニター]のショートカットをクリ
成功するPhoneGapアプリを開発するための高速化＆UXテクニック
興味深いブログ記事が海外で掲載されていました。拙訳で恐縮ですが紹介したいと思います。 内容はPhoneGapアプリを高速化するための手法の解説で、具体的な事例とともに、いくつかのテクニックの紹介が行われています。少し長い記述になりますが、是非PhoneGapやMonacaを用いた開発の参考にしてください。 成功するPhoneGapアプリを開発するための高速化＆UXテクニック Performance & UX Considerations For Successful PhoneGap Apps PhoneGapアプリを開発する方から、下記のような質問をよく尋ねられます。 ・アプリを高速化する方法は？ ・どうやってネイティブアプリのような質感を出せるか？ ・プラットフォームに違和感のないアプリを作るためのテクニックは？ ・OSのルック＆フィールとマッチさせるためには？ この記事では、素晴らし
Archived MSDN and TechNet Blogs | Microsoft Docs
Archived MSDN and TechNet Blogs 1/21/2020 2 minutes to read MSDN and TechNet blog sites have been retired, and blog content has been migrated and archived here. Archived blogs are grouped alphabetically by the initial letter of the blog name. Blogs and blog posts can be searched by their names, using the Search box at the top of the page. Actively updated blogs have been moved to other blog sites,
Linux OSリソースのパフォーマンス分析(1) ～ OSリソースを取得してみよう
「まかせいのう」は、システム開発・運用の改善や設計を専門に行うNTTデータのコンサルタントチームです。 OSリソースとは 最初に、サーバのOSリソースにはどのような種類があるのかを整理しておきましょう。OSリソースは大きく以下の4つに分類できます。 CPU メモリ ストレージ ネットワーク 「CPU」と「メモリ」はイメージしやすいと思います。これらはサーバマシンが持っているリソースです。個人用PCを買う際にも、性能（パフォーマンス）を判断するスペックとして使いますね。 「ストレージ」は、サーバ内蔵の場合もあれば、専用のストレージ製品を外付けにして使う場合もあります[1]。多くの場合、ハードディスクが使われますが、最近はより高性能なSSDなどフラッシュストレージの利用も増えてきました。「ネットワーク」は、LANケーブルのようにサーバやストレージなど機器を接続しているもので、帯域の太さが重要に
HTTP リクエストの処理完了までの所要時間をログに記録する
Landscape トップページ | < 前の日 2005-12-27 2005-12-28 次の日 2005-12-29 > Landscape - エンジニアのメモ 2005-12-28 HTTP リクエストの処理完了までの所要時間をログに記録する 当サイト内を Google 検索できます * HTTP リクエストの処理完了までの所要時間をログに記録するこの記事の直リンクURL: Permlink | この記事が属するカテゴリ: [IIS] [Apache] [http] http リクエストの処理にかかった時間をロギングする方法のメモ。 集計や分析、パフォーマンス劣化の監視などで活用するため、http サーバ側でリクエストを処理したあとレスポンスを返すまでどれだけ時間がかかったかを記録したい。 所要時間などの値は http サーバ上で動くアプリケーション側でロギングする仕組みを作るの
KOSHIGOE学習帳 - [MySQL] パフォーマンス関連メモ
{{toc_here}} InnoDB パフォーマンスチューニング MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Ma
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
MyISAMからInnoDBへ切り替えるときの注意点
MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな
＠IT：httpd.confによるWebサーバの最適化（1/3）
などに配置されています。 なお、httpd.confの更新内容を有効にするには、httpd.conf編集後にApacheを再起動する必要があります。Apacheの再起動は、第1回の「起動／終了、サービスの登録」を参考にしてください。 不要な機能、設定の削除 不要なモジュールの削除 Apacheは、モジュールによって機能を追加することができます。Apacheインストール時に組み込まれているモジュールは、以下のようにして確認できます。
Apacheパフォーマンス・チューニングの実践
セッションのチューニング ここまでのチューニングは、必要か必要でないかを判断すればよく、手探りで最適な値を探し出すというものではなかった。しかし、これから紹介する「セッションのチューニング」はそうもいかない。ある程度の見通しは立てられても、最適な答えを見つけるのには手間がかかってしまう。 KeepAliveとセッションの切断 セッションのチューニングの手始めとして、「KeepAlive」について考えることにしよう。KeepAliveはHTTP/1.1から用意されたもので、クライアントとの接続を保持する仕組みである。HTTPは「ステートレス・プロトコル」と呼ばれるとおり、1回の要求（リクエスト）ごとに接続が切断される。しかし、今日では1つのWebページを表示するために複数のファイルが必要となる場合がほとんどなので、1リクエストごとに接続を切っていたのでは効率が悪い。そこで考え出されたのがKe
CentOS6で制限されているプロセス最大数を制限解除する - 256bitの殺人メニュー
ハマったのでメモ。 Linuxでリソース制限するための仕組みのulimitがありますが、その1項目に「nproc」があります。 これはそのユーザで実行できるプロセス（スレッド）数の制限となります。 これが、CentOS5までは、 $ ulimit -u unlimitedのように無制限だったのですが、CentOS6になって以下のように1024で制限がかかるようになりました。 $ ulimit -u 1024そのため、デーモンとかで高負荷な処理をさせてプロセス（スレッド）が増えると処理が落ちてしまうのです。 悲しいけどこれってデフォルト値なのよね。 設定箇所は？ 実際の設定は、[/etc/security/limits.d/90-nproc.conf]でされています。 # cat /etc/security/limits.d/90-nproc.conf # Default limit for
パフォーマンス改善やセキュリティに役立つ.htaccessの設定 | コリス
ウェブサイトのパフォーマンスの改善やSEO、セキュリティに役立つ.htaccessの設定を紹介します。 17 Useful Htaccess Tricks and Tips 備考：Apache チュートリアル: .htaccess ファイル、Apache コア機能 [ad#ad-2] .htaccessの設定：パフォーマンスやSEO関連 .htaccessの設定：セキュリティ関連 .htaccessの設定：パフォーマンスやSEO関連 .htaccessでタイムゾーンを設定 .htaccessでタイムゾーンを設定します。 例：東京 SetEnv TZ JST-9 もしくは、 SetEnv TZ Asia/Tokyo .htaccessで301リダイレクトを設定 .htaccessで301リダイレクト（永続的なリダイレクト）を設定します。 例：旧ファイル（old.html）、新ファイル（new
CSSセレクタの高速化の話し - Webtech Walker
続・ハイパフォーマンスWebサイトを読んでCSSセレクタの高速化の話しが面白かった（というか全然知らなくてちょっとびびった）ので紹介します。 セレクタは右から左に解釈される これは正直知らなくて、結構衝撃でした。 #foo .bar {} これはなんとなく#fooを探して、その中の.barを探している気がしてたんですけど、実は.barを探して、その親要素に#fooがあるかを探すそうです。なので特に#fooが必要なければ .bar {} と書いたほうが高速だということ。 また、以下の様に要素名で指定すると、その要素を全て探します。 #foo a {} これは一度a要素を全て探すので、できればaにclassをふって #foo .anchor {} とするほうが高速のようです。（#fooをとるとより高速） 特にユニバーサルセレクタなどは、 #foo * {} とすると、全ての要素の親要素に対して
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ
bayashi.net