Shin x blog Advent Calendar 2013 の 6 日目です。 とあるサイトに、Varnish をリバースプロキシとして導入して、半年が経過しました。 導入した経緯やその効果など書いてみたいと思います。 Varnish とは Varnish は、HTTP アクセラレータです。Web サーバのリバースプロキシとして動作し、キャッシュを生かして高いパフォーマンスを発揮するのが特徴です。また、VCL という独自の設定言語を持ち、これにより状況に応じた設定を柔軟に行うことができます。 導入の経緯 このサイトでは LAMP 構成の CMS を利用しており、インフラには AWS を利用しています。基本、閲覧が中心なのですが、イベント時に多数のアクセスがあります。S3 や CloudFront も検討したのですが、コンテンツを数分おきに更新する必要があるので今回は採用しませんでした
2016/07/09、10 に大阪大学 豊中キャンパスで開催された WordCamp Kansai 2016 にて、WordPress サイトのチューニングについて発表しました。 https://twitter.com/digitalcube/status/751693759121731584 発表資料 今回は、PHP（WordPress）エンジニアでなくても何か役立ててもらえるようにチューニングの具体的な手法というよりは、実際に手を動かすエンジニアと意思疎通がスムーズになるように基本的な考え方をメインにお話しました。 「推測するな、計測せよ」という格言があるとおり、チューニングにおいても、まず大事なのは「計測する」ということです。計測せずにやみくもにチューニングを行っているケースを見聞きするので、ここからはじめる内容にしました。 後半は、キャッシュを中心に紹介したのですが、最後の Var
最近、はてブを眺めていたら、面白いツールを紹介されていましたので、早速CakePHPで使ってみた、というレポートです。 これは面白い!! 自分の組んだPHPプログラムが、本当に丸裸。どこがボトルネックになっているか、一目瞭然です。 というわけで、早速ですがCakePHPも、このツールで解析してみることにしましょう。 とりあえず簡単に手順をまとめておきます。 環境によって適用方法が異なると思いますので、その辺は良きに計らってください。 １：xprofのインストール xhprofはpeclのプロジェクトです。 peclツールを使って自動インストールすることも出来るみたいなのですが、当方の環境ではphpizeでエラーが出るため、マニュアルインストールしました。 ▼pecl : xhprof http://pecl.php.net/package/xhprof コンパイル及びインストール方法は次の
PHPプログラムを解析して何処が重いか？がブラウザ上で簡単に分かる「XHProf」 2009年03月25日- XHProf Documentation (Draft) PHPプログラムを解析して何処が重いか？がブラウザ上で簡単に分かる「XHProf」。 通常、PHPでのプロファイリングというと、Xdebugでファイルを吐き出して、WinCacheGrindやKCacheGrindで読み込むというのが定番です。 ですが、この方法だと、ファイルを吐き出したファイルをGETして、ソフトに読み込ませる、というちょっと面倒な手順が必要でした。 XHProf を使えば、ブラウザ上で、プロファイリングが出来るみたいです。 XHProfの特徴 まず、セグメントごとの実行時間やメモリ利用の状況なんかがブラウザで見れます。 プログラムの構造を把握するのにも使えます。 プロファイリングの階層表示 ２つのプロファ
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
今日はさくらVPSに載せているWordPressのパフォーマンスをチューニングして高速化に成功したので安心して眠れるという話をします。 2.5ページ/秒だったのが70ページ/秒と30倍高速化。 以前はDaily数千PVで重くなっていたサイトがDaily3.6万PVを余裕で捌けるようになりました。 #ちなみにproxy cacheという手法はwordpressでなくても動的コンテンツ全般に有効です。 ▼サーバ気にしなくて良くなったので今週末新宿御苑に花見に行けました☆。枝ぶりがいいさくらが多くてほんといいところだと思うの。 WordPressチューニング高速化結果http://hara19.jp/のサーバ環境と測定結果は以下のとおり。 WordPress稼働環境さくらVPS 1GB/CentOS5.5/PHP5.3/MySQL5.5/WordPress3.1。 WEBサーバはチューニングにあ
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Accident Lawyers 10 Best Mutual Funds Healthy Weight Loss Top 10 Luxury Cars All Inclusive Vacation Packages Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
GoogleがWeb全体のスピードアップにいよいよ本格的に着手, 一社だけではできないと強調 からリンクのあった、 http://code.google.com/intl/ja/speed/articles/optimizing-javascript.html が日本語かと思ったら日本語じゃなかった・・・・。 いやー、意外とというか文字列については、全然知らんかった。 Closureって便利だし、「おぉ〜俺って使ってるジャン」みたいな気になれるからついつい使っちゃうんだけど、高コストなのね・・・・。反省。 ということで、超適当翻訳。どっかの誰かが書いてるかも。 前おき 著者: Google Chromeのエンジニア Gregory Baker, Software Engineer on GMail & Erik Arvidsson 推奨される経験：JavaScriptの実践的な知識 クライ
Rails Web アプリケーションをもっと速く こんなストーリーを考えてみます。 あなたは、Railsを学び、アプリケーションを作成し、サービスをインターネットに公開しました。しばらくすると、最初のユーザができます。あなたはとてもハッピーです。そうするうちにユーザが二人増え、十人になり、百人になりました。あなたはハッピーです、ユーザーもみんなハッピーです。 でも、ユーザが千人になり、一万人になり…。といった場合、何が起こるでしょうか？ そこで起こるのはアプリケーションへの同時接続数増加によるサービス提供速度の低下です。ユーザ数が一万人を越えてしまうWebサーバに特有の問題は、C10K問題として知られています。 それでなくとも、残念ながらRailsは同様他種フレームワークと比べて、単位時間あたりの処理量が低いことで知られています。その理由は、RailsではRubyが遅くて、NativeTh
PHP コード最適化 Best Practices 63+ - カタコト日記 前回は、元記事に一定の敬意を表して、項目とかはあえてそのままにしてたんですが、 自分としても気になる部分が多々あったので、少しだけ調べ直して優先度＆解説つけました。 独断と偏見ですが。ヽ(´ー｀)ノ 検証はしてません。ごめんなさいごめんなさい。 優先度A、B、C、不明、非推奨に分けてみました。どうぞつっこんでください。 長いよ、今回は。 優先度A. 頻度も高いし使えそう - 6つ 01. static にできるメソッドは static として宣言しよう。（4倍速い） 正しくは、static なメソッドには、OOP のルールに従ってちゃんと static 宣言をつけよう！ ってとこでしょうか。本来そうでないものを無理に static にしちゃえって話ではないはず。*1 × <?php public function
いやなブログ: 日本語テキストをテーブルで表示するの高速化バージョン。 DOMでのHTML組み立ては非常に遅くてJavaScriptの配列で組み立ててから 一気にinnerHTMLに代入したほうが速い。特にIEの場合は差が顕著、5倍ぐらいは速いはず。 DocumentFragmentを使うという手もあるが、2倍程度にしか速くならなかった。 innerHTMLを使ったほうが良い、というわけではなくて時と場合によりけり。 innerHTMLとappendChildを組み合わせて使うと大体の場合最速。 こういうやつ tmp = document.createElement("div"); tmp.innerHTML = 複雑なHTML; body.appendChild(tmp); body.innerHTML += tmp.innerHTML は絶対に避ける。innerHTMLの読み書きは、ど
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
