タグ

tuningに関するsunabakoのブックマーク (9)

  • ピンポイントでデフラグできる高機能フリーソフト「Power Defragmenter」 - GIGAZINE

    SysinternalsのContig.exeというデフラグエンジンを使用して強力かつ高速なデフラグが可能になるというすさまじいフリーソフト。Sysinternalsは現在、マイクロソフトによって買収されているため、このデフラグエンジンの信頼性もかなり高いと判断して差し支えありません。 また、このデフラグソフトの特徴は有料のデフラグソフトでないと無理だった、「フォルダのみをデフラグ」や「ファイルのみをデフラグ」といった機能が使えるところ。これによって大量にファイルがあるフォルダを開く場合や、山ほどフォルダが存在する場合の妙な引っかかりを軽減させることが可能です。 というわけで、実際の使い方は以下から。 まずは以下のサイトから体となる「Contig」をダウンロード。これはコマンドラインで操作するソフトです。 Contig v1.53 次に以下のサイトから「Power Defragmente

    ピンポイントでデフラグできる高機能フリーソフト「Power Defragmenter」 - GIGAZINE
  • 徒然なるままにBlog - Apacheチューニング: ロギングを高速化する

    あまり知られていません(と思われる)がApache2(2.0.41以降)にはアクセスログの書き出しをメモリにバッファリングし高速化させるという機能があります。 今回はその機能を有効にするとどれぐらい速くなるのか調べてみました。 設定方法はhttpd.confに BufferedLogs On と追加するだけでログのバッファリングが有効になります。 以下ベンチマークを取った結果です。 バッファリング無効984 Request/Sec バッファリング有効1033 Request/Sec (参考)ロギング無し1055 Request/Sec ※小さなhtmlファイルに対してab -c 100 -n 1000を何度か繰り返した結果の平均です。 体感では違いを感じられないとは思いますがベンチを取るとおよそ5%程Request per secondの値が上がっていました。 静的なファイルが

  • AsyncIOについて(その2) - 最速配信研究会(@yamaz)

    AsyncIOについて(その1)の続き. NONBlockでIO処理をする方法としてselectとシグナルを使う方法があるというのが前回の話だったが, selectはselectよりkqueue,epollで述べたとおり, ビジーループがかかるためあまり効率はよくなく,シグナル方式は制約があるためあまり使い勝手がよくない. というわけで新しく出てきたのがPOSIX Asynchronous I/O(AIO)という機構だ. これはIOのwaitをイベントドリブン形式にしてビジーループをなくそうというものだ. プログラムの流れとしては下記のようになる. 1. 対象となるファイルディスクリプタにシグナルハンドラもしくはイベントハンドラを登録しておく 2. aio_read/aio_writeを呼び出すと制御はすぐにユーザに戻る. 3.対象のファイルディスクリプタの処理が終わると登録されていたハン

    AsyncIOについて(その2) - 最速配信研究会(@yamaz)
  • AsyncIOについて(その1) - 最速配信研究会(@yamaz)

    最近のOSにはAsyncIO(AIO)という新しいI/Oの仕組みが導入されているようだ.lighttpdの次期バージョンではAIOを導入することで8割もパフォーマンスが上がったようで非常に興味深い. またあちこちのBlogを見る限りNonBlockingI/OやNonBlockingI/O+シグナルとAIOが混同されている気がしたので,それら整理してみたい. はじめに I/O処理であるシステムコールのread/writeは対象がディスクだったり,ソケットだったりデバイスだったりするわけだが,通常これらのIO処理はCPU処理やメモリ処理に比べ非常に遅いことが知られている. 通常readが行われるとreadが終わるまで,永遠に処理は戻ってこず,プロセス的には待ち状態になってしまう.これは「Blocking」と呼ばれる. 遅いディスクやデータがいつ来るかわからないソケットなどに対するIO処理では

    AsyncIOについて(その1) - 最速配信研究会(@yamaz)
  • Windows XP の動作を軽快にしたい - mtblue.org

    ご案内:このページ「Windows XP の動作を軽快に(軽量化・高速化)したい」は、ウェブサイト「 mtblue.org 」の中のページの一つです。サイト内のページを少しでも効率よく参照していただけるよう、次の機能を提供しています。ご利用ください。 サイト内検索 サイトマップ また、トップページからこのページまでのアクセスの経路を示す情報を提供しています。この情報は、ページの先頭付近と終端付近で合計二度提供されていますので、この情報が二度目に出現した箇所を、ページの終端と捉えていただくことができます。一度目の出現はこのご案内の直後です。すなわち、次のような形式で提供しています。以上で、ご案内を終わります。 HOME > PC関連 > ちょっとしたTips > Windows XP の動作を軽快に(軽量化・高速化)したい Windows XP は、軽快に動作するよう設計されていますが、シス

  • 最速配信研究会 - ロードバランサの運用.DSRって知ってますか

    id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない>DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン

    最速配信研究会 - ロードバランサの運用.DSRって知ってますか
  • Michael J. Radwin talks

    2006 Hacking Apache HTTP Server at Yahoo!, Thursday, July 27, 2006 (OSCON 2006) Slides in HTML | PDF | PPT Since 1996, Yahoo has been running Apache HTTP Server on thousands of servers and serving billions of requests a day. This session reveals the secrets of how Yahoo gets maximum performance out of minimal hardware by tweaking configuration directives and hacking the source code. Radwin will

  • オープンソースの高速Webサーバー「TUX」の実力

    図5●プラットフォームの違いによる,コネクション確立の所要時間の差異<BR>TCPコネクションが確立するまでの時間を調べた。TUX 3.2はチューニング前後の数値にそれほど大きな違いはなく,比較的安定している。一方でApacheは標準設定時に扱えるプロセス/スレッド数が小さいため,Fedora Core 2.0とApache 2.0の組み合わせにおいてコネクション確立に要した最大時間が3009ミリ秒に達した。チューニングによって扱えるコネクション数を増やしたApacheでは,コネクション確立までの平均時間と最大時間が,いずれもTUX 3.2の性能をしのいでいる カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX Web Server」(以下,TUX)の性能を,現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で,TUX 3.2はApache

    オープンソースの高速Webサーバー「TUX」の実力
  • GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ

    というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日(火)の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日(水)12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根的に間違っているのだろうか?それとも、もうGIGAZINEサーバのハード

    GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
  • 1