タグ

パフォーマンスに関するremixedのブックマーク (5)

  • PowerShell スクリプトのパフォーマンスに関する考慮事項 - PowerShell

    PowerShell スクリプトは、.NET を直接利用してパイプラインを回避する方が、慣例的な PowerShell より高速になる傾向があります。 慣例的な PowerShell では、コマンドレットと PowerShell 関数を使用し、多くの場合パイプラインを活用し、.NET を使用するのは必要なときだけです。 出力の抑制 パイプラインへのオブジェクトの書き込みを回避するには、さまざまな方法があります。 $null に代入する [void] にキャストする $null へのファイル リダイレクト Out-Null へのパイプ $null への代入、[void] へのキャスト、$null へのファイル リダイレクトは、ほぼ同じ速度です。 ただし、大きなループで Out-Null を呼び出すと、特に PowerShell 5.1 では大幅に遅くなることがあります。 $tests = @

    PowerShell スクリプトのパフォーマンスに関する考慮事項 - PowerShell
  • リーダーになるすべての人に知ってほしい ヒトに関する問題解決の極意

    What、Where、When、HowのISとIS NOTを押さえることで、初めてA君の状況が見えてきます。上司の直感で「A君はダメだ」と決めつける場合と比べて、状況認識に広がりと深さが出てくることがわかると思います。 情報の品質という観点からもこのようなシステマティックなアプローチは威力を発揮します。ヒトに関する良質な情報は収集が難しいので、怪しげな情報が横行する危険性が常にあります。ところが、目についた否定的なIS情報だけでなくて、IS NOTという対照情報も探すとなると、自ずと情報がスクリーニングされることになります。 比較に耐える情報を探さなければならないので、直接情報(自分が直接見た)なのか、間接情報(他人が直接見たことを確認した)なのか、噂(誰が見たかわからない)や臆見(根拠の薄弱な情報に基づいた主観的意見)なのか、ということが気になるからです。こうして、正しいものだけ受け入れ

    リーダーになるすべての人に知ってほしい ヒトに関する問題解決の極意
  • 6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst

    NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか? Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を

    6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst
  • パフォーマンスモニタの監視項目:老プログラマーの備忘録:SSブログ

    システム監視は、監視目的(ボトルネック、エラーや使用状況の検出)を明確にしておくことです。しかし、幾つかの項目の閾値は一般的な数値として定義できますが、多くの項目はシステム運用中にデータを取得しシステムに適合できる閾値を見極めることが大事だと思います。 扱う項目や依頼数の変化と監視項目の変化のデータを取り将来起こりうるボトルネックや障害を予想する為にもデータは日々取得し日次、週次、月次、半期及び年次などで分析を行う必要があります。 監視する項目 ・CPUのボトルネックと使用状況 ・メモリのボトルネックと使用状況 ・ディスクのボトルネックと使用状況 ・ネットワークのボトルネックと使用状況 スループット スループットは単位時間(秒)当たりにシステムが実行できる処理数 ボトルネック ボトルネックは、システムが処理を行っている時にリクエストからレスポンスを返す過程で滞留を起こしスループットの低下の

    パフォーマンスモニタの監視項目:老プログラマーの備忘録:SSブログ
  • Apacheのチューニングメモ - Qiita

    個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい! prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 (以下正確ではないですが簡単に) Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた

    Apacheのチューニングメモ - Qiita
  • 1