タグ

チューニングに関するmasudaKのブックマーク (141)

  • ApacheでCGIを使う場合にpreforkを使った方が良い状況とそのチューニングについて - 人間とウェブの未来

    かなり今更感の漂う内容ではありますが、意外と情報が分散していたり、Apache2.4系を考慮した場合に足りていない内容があったのでこのエントリで一度まとめてみようと思います。 CGIを使うようなシステムでそれなりにアクセスが集中するサーバ、例えば日々のピーク時のApacheのbusyワーカー数が1000になるようなサーバで、かつ、それを処理可能なマシンスペックのサーバであることを前提にしています。 ApacheのMPMCGI実行アーキテクチャの復習 ApacheでCGIを使う場合には、MPMCGI実行アーキテクチャの組み合わせは大きく分けて以下の2つに分ける事ができます。 worker(event) + mod_cgid prefork + mod_cgi Apacheの2.4系から特にworker(event) + mod_cgidのモデルが推奨されているようです。また、2.4系では

    ApacheでCGIを使う場合にpreforkを使った方が良い状況とそのチューニングについて - 人間とウェブの未来
  • 阿部寛のサイトを高速化する - Qiita

    ちまたで阿部寛のサイトが早いと話題になってます。 dev.toと阿部寛のホームページどっちが速いですか? dev.toと阿部寛のホームページについてちゃんと計測させてくれ 阿部寛のサイトはベストを尽くしてるのか? それを調べるために、阿部寛のサイトを高速化させてみたいと思います。 目指すべきスピード 最速はローカルのファイルへのアクセスだと思うのでこれを目指したいと思います。 file:///C:/abe_hiroshi/index.html ChromeのDeveloper Toolでレンダリング完了が「173ms」でした。 まぁここまでは無理だな… 阿部寛のサイトはどんなもん? 速度はwebpagetest.orgで測ってみます。 レンダリング完了時間は「359ms」です。はえーな S3でホスティングしてみる サーバーを立てるほどでもないので、S3でWebホスティングしてそこにhtml

    阿部寛のサイトを高速化する - Qiita
    masudaK
    masudaK 2017/11/18
    阿部寛最強。
  • CPU使用率100%のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来

    こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ

    CPU使用率100%のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
  • PHPのちょっとしたコツ

    ウノウラボ Unoh Labs: PHPのちょっとしたコツに興味深い内容が書かれています。 1. array_pushは遅い いくつかのBlogで語られてることですが、array_pushは、次のような書き方のほうが早いそうです。 //array_puth($array, \'arraydata\'); $array[] = \'arraydata\'; ウノウラボ Unoh Labs: PHPのちょっとしたコツ これはほんとあちこちで言われていますね。実際にどの程度違うかベンチマークを取ってみました。 < ?php require_once 'Benchmark/Timer.php'; $max = 10000; $timer = new Benchmark_Timer(); $timer->start(); $array = array(); for ($i = 0 ; $i < $m

  • 雑なMySQLパフォーマンスチューニング

    【第26回Elasticsearch勉強会】Logstashとともに振り返る、やっちまった事例ごった煮Hibino Hisashi

    雑なMySQLパフォーマンスチューニング
    masudaK
    masudaK 2016/01/27
    やばい、見きれないw
  • SSL のパフォーマンスでお嘆きの貴兄に - What I’ve found has never been enough@Hatena

    SSL アクセラレータの価格に胃を痛めている貴兄、それが買えず SSL のためだけにサーバの台数をニョキニョキ増やしている貴兄、そうでなくとも SSL のパフォーマンスでお嘆きの貴兄のために、いろいろまとめてみましたよ。 SSLセッションキャッシュのタイムアウト設定を長くしよう SSL の負荷のほとんどはセッションの生成によるものなので、当然のようにサーバ側の SSL セッションキャッシュを有効にしておられると思いますが、そのタイムアウトの設定がデフォルトのままという方が多いのではないでしょうか。 たとえばApacheでしたら、設定サンプルのまま SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) SSLSessionCacheTimeout 300 としている方が多いのではないでしょうか。 各サーバのデフォ

    SSL のパフォーマンスでお嘆きの貴兄に - What I’ve found has never been enough@Hatena
  • サーバーさんに本気を出してもらうために憶えておきたい設定項目

    cpuspeed がオンだと.... — はせがワン (@hasegaw) 2014, 5月 29 ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。 経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。 パワーマネジメントに関する設定はオフにする UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。 Hyper Threading はレイテンシーとスループットのトレードオフ Hyper Threadingは、たぶん、コア内でパイプラインを取り合うから

  • 「超チューニング祭 ~ニコニコを超快適にしてみた~ in ニコニコ超会議3」の問題点 - Webパフォーマンスについて

    来る2014年4月26日(土)・27日(日)に、「ニコニコ超会議3」が開催され、その中で「超チューニング祭 ~ニコニコを超快適にしてみた~」が開催されるそうです。 これは、現行のスマートフォンサイトのTopページのソースファイルを競技者がチューニングして、速度やデザイン・UIの改善をして、速度と使い勝手を競うのだそうです。 「これは面白そうだ! 会場は家から近いし!」と思って参加するつもりでいましたが、事前調査で計測してみた結果、フロントエンドのチューニングでは速くならないことがわかったので、その内容について説明します。 (主催者の方にも、フロントエンドのチューニングでは速くならないという情報は伝えてあります。) まずは、計測データ まずは実際のトップページ(http://sp.nicovideo.jp)の計測データを見てみましょう。 計測は、NTT DoCoMoとSoftBankの3G回

    「超チューニング祭 ~ニコニコを超快適にしてみた~ in ニコニコ超会議3」の問題点 - Webパフォーマンスについて
  • Linuxカーネルチューニングのメモ - 電子書籍と趣味の部屋

    Post navigation ← Previous Home > Web関連 > 開発 > Linux > Linuxカーネルチューニングのメモ Linuxカーネルチューニングのメモ サーバー向けにLinuxカーネルのチューニングを行った際のメモです。 設定内容 今回行った /etc/sysctl.conf の設定内容は書きの通りです。 各パラメータの説明はコメントとして残しておきます。 # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824 # システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144 # システム全体のプロセス数の上限 kernel.threads-max = 1060863 # システム全体のファイルディスクリプタの上限 fs.file-max = 5242880

  • DNSキャッシュサーバ チューニングの勘所

    PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)NTT DATA Technology & Innovation

    DNSキャッシュサーバ チューニングの勘所
  • Java HotSpot VM Options

    Please note that this page only applies to JDK 7 and earlier releases. For JDK 8 please see the Windows, Solaris reference pages. This document provides information on typical command-line options and environment variables that can affect the performance characteristics of the Java HotSpot Virtual Machine. Unless otherwise noted, all information in this document pertains to both the Java HotSpot C

  • Top 84 MySQL Performance Tips | Debian Admin

    MySQL is a widely used and fast SQL database server. It is a client/server implementation that consists of a server daemon (mysqld) and many different client programs/libraries. You can check the same tips from here.Here is very useful tips for all mysql DBA’s,Developers these tips are noted from MySQL Camp 2006 suggested by mysql community experts. Kaj (Most Excellent Obvious Facilitator) Index s

  • @IT:Javaのヒープ・メモリ管理の仕組み

    GC前、Eden領域の消費サイズは「1834928」バイトであった GC後、Eden領域の消費サイズは「0」バイトであった(つまり全オブジェクトが移動もしくは破棄された) GC後、Eden領域のサイズは「3670016」バイトであった 「survivor」とは、From領域とTo領域両方を指します。ここでもし、上記ログのようにGC後のFrom/To領域の消費サイズが「0」となった場合は注意が必要です。これはすなわち、オブジェクトがFrom領域とTo領域の間を行き来せず、すぐにOLD領域に移動してしまっていることを表します。このような状況では、OLD領域は短命なオブジェクトですぐに埋まり、Full GCが頻発してしまいます。これはオーバーフローと呼ばれ、MaxTenuringThreshold値の低い状態で一連のGCが発生している状況を見つけることで検出できます。 NEW領域のサイズ調節 M

    @IT:Javaのヒープ・メモリ管理の仕組み
  • IO Accounting 機能で I/O 負荷の高いプロセスを特定

    随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を

  • JBoss AS 7のJava VMチューニング - nekop's blog

    JBoss Advent Calendar 2011の15日目のエントリです。JBoss AS7 はじめの一歩で少し書いたんですが、だいぶ古くなっているのと少々解説を。今回はJBoss AS 7.1.0.Beta1とFedora 16のOpenJDK 6 64bitを利用します。 $ java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.4) (fedora-61.1.10.4.fc16-x86_64) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) チューニングしていない状態 JBoss AS 7.1.0.Beta1の出荷時のJava VMオプションは$JBOSS_HOME/bin/standalone.confに定義され

    JBoss AS 7のJava VMチューニング - nekop's blog
  • HotSpot VMの特性を知る

    Permanent領域のチューニング JVMにはPermanent領域と呼ばれるヒープ領域があります。ここにはクラス定義やメソッド、フィールドなどのメタデータが格納されます。 Permanent領域のデフォルトのサイズは、一般的なアプリケーションにとって十分な大きさに設定されています。しかし、アプリケーションによっては非常に多くのクラスをロードするものもあり、Permanent領域が足りなくなることがあります。例えば、JSPやサーブレットを多用するアプリケーション(アプリケーションサーバなど)は、デフォルトのPermanent領域サイズでは足りなくなり、次のようなエラーが発生することがあります。 $ java ManyClassLoadingTest Permanent generation is full... increase MaxPermSize (current capacity

    HotSpot VMの特性を知る
  • 第3回 チューニンガソン番外編 一人 チューニンガソン - かれ4

    今回からは運営側として参加のチューニンガソン 準備編 まず一番大変だったのが、テーマの決定 色々話しあって erlangのtwoorlを暫定でテーマに このtwoorlが曲者で動かすためには yaws,ErlyWeb,erlangと難関が待ち構えています。 yaws,ElryWeb,erlangは行けるものの、 どうしても運営側の誰もtwoorlを動かすことに成功できず諦めました。 そのあと出てきたテーマがjavaのCMS blojsom これが今回のテーマです。 これを動かすまでも結構な苦労が。。。 tomcatをいじったことのない人達が何とか動かすところまでいけたので、とりあえずテーマは確定で その間の試行錯誤(情報がやたら少ないand古いバージョン用のせいで)は大変でしたが、省略。 そして、計測の方法やなにやらを決めて、 実際に自分でチューニングしてみて、チートの可能性を見つけること

    第3回 チューニンガソン番外編 一人 チューニンガソン - かれ4
    masudaK
    masudaK 2012/03/26
    やっぱ人のアプローチ見るのは勉強になるなぁ。
  • TomcatのJVM(Java Virtual Machine)チューニング例 - 銀の鍵

    One thing to realize about our fractional reserve banking system is that, like a child's game of musical chairs, as long as the music is playing, there are no losers. Andrew Gause, Monetary Historian 「部分準備金融制度について一つだけ実現している事は、 子供の椅子取りゲームのように、 音楽が流れ続けている限りは敗者が存在しないということである。」 アンドリュー ガウス、金融史家 【Sun HotSpot VMのガベージコレクションとヒープ】 TomcatはApache Software Foundationが提供するフリーのサーブレットコンテナ実装です。要するにJ

  • masuidrive on rails - RailsアプリをチューニングするならNew Relic RPM

    Photo by Riverman72 あとで自分メモを書こうと思うけど、先に一言。 37signalsも使っているといううたい文句に惹かれて試してみた、Railsのパフォーマンス記録ツール/サービスNew Relic RPM(Rails Performance Management)が、すばらしい。 RPMは開発時用のDeveloperと、実機用のProductionのが二つあり、まだ開発時用のDeveloperモードしか試してはいないんだけど、専用の管理画面で、アクションを実行時のメソッド単位の実行時間、生成されるSQLSQLの実行時間やインデックスの利用状況などが非常に簡単に把握できます。 Railsで開発している人なら、下のムービーを見れば、そのすごさが分かるはず。 RPM developerのデモ動画 | RPM production のデモ動画 いまこれを使って、PhotoS

  • WEBサイト負荷テストツール7選 | さぶみっと!JAPAN

    WEBサイトに情報を入力するだけで負荷テストができるLoad Impact、GUIから操作できるApache JMeterや、コマンドラインから使うcurl-loader・httperf・Siege・Pylot・abを簡単な使い方と共に紹介していきます。 Load Impact http://loadimpact.com/ Load ImpactはスゥエーデンのGatorhole AB社が管理している、フォームに必要な情報を入力するだけで負荷テストをしてくれるWEBサイトです。 ツールをインストールしたりする必要が有りませんので、非常に楽です。 毎月5回まで無料で負荷テストができます。 それ以上は10回/$30のクレジットを購入する事になります。 トップページのフォームにURLを入れて「Run free test」をクリックすると、世界各地のいずれかのAmazon EC2サーバから負荷テス

    WEBサイト負荷テストツール7選 | さぶみっと!JAPAN