速度とスケーラビリティのためにコハナベースのウェブサイトを最適化する

Question 1

私がコハナで構築したサイトは昨日大量のトラフィックで非難され、一歩下がってデザインの一部を評価することになりました。コハナベースのアプリケーションを最適化するためのいくつかの標準的な手法に興味がありますか？

ベンチマークにも興味があります。私はセットアップする必要がありますBenchmark::start()し、Benchmark::stop()すべてのページの実行時間を確認するために、各コントローラ-法のために、または私は世界的にかつ迅速にベンチマーク適用できるのですか？

今後、キャッシュライブラリをさらに使用する予定ですが、現時点では気付いていないことがたくさんあると確信しているので、さらに多くの提案を受け付けています。

Question 2

この回答で私が言うことは、コハナに固有のものではなく、おそらく多くのPHPプロジェクトに適用できます。

パフォーマンス、スケーラビリティ、PHPなどについて話すときに頭に浮かぶいくつかのポイントがあります...
私はいくつかのプロジェクトに取り組んでいる間、それらのアイデアの多くを使用しました-そしてそれらは役に立ちました。だから彼らはおそらくここでも助けることができるでしょう。

まず第一に、パフォーマンスに関しては、考慮すべき多くの側面/質問があります：

サーバーの構成（Apache、PHP、MySQL、その他の可能なデーモン、およびシステムの両方） ; ServerFaultでそれについてもっと助けを得るかもしれませんでそれ、私は推測します、
PHPコード、
データベースクエリ、
Webサーバーを使用しているかどうか？
どんな種類のキャッシュメカニズムも使用できますか？それとも、ウェブサイトに常に最新のデータが必要ですか？

リバースプロキシの使用

本当に役立つ最初のことは、Webサーバーの前でvarnishのようなリバースプロキシを使用することです。可能な限り多くのものをキャッシュするようにして、PHP / MySQL計算（そしてもちろん、他のいくつか）を本当に必要とするリクエストのみをキャッシュします。リクエストは、プロキシのキャッシュにない場合）、Apache / PHP / MySQLに送信されます。

まず第一に、CSS / Javascript / Images-まあ、静的なものはすべて-おそらく常にApacheによって提供される必要はありません
- したがって、リバースプロキシにそれらすべてをキャッシュさせることができます。
- これらの静的ファイルを提供することはApacheにとって大したことではありませんが、それらのために機能する必要が少ないほど、PHPでより多くのことができるようになります。
- 注意：Apacheは、一度に限られた数のリクエストしか処理できません。
次に、リバースプロキシにキャッシュからできるだけ多くのPHPページを提供させます。おそらく、それほど頻繁に変更されないページがいくつかあり、キャッシュから提供される可能性があります。PHPベースのキャッシュを使用する代わりに、別のより軽量なサーバーにそれらを提供させてみませんか（そして、PHPサーバーから時々フェッチするので、常にほぼ最新です）？
- たとえば、頻繁に要求されるRSSフィード（パフォーマンスを最適化しようとすると、通常はそれらを忘れがちです）がある場合、それらを数分間キャッシュに保存すると、Apache + PHPへの数百/数千の要求を節約できます。 + MySQL！
- サイトで最も訪問されたページについても同じですが、少なくとも数分間変更されない場合（例：ホームページ？）、ユーザーが要求するたびにCPUがページを再生成するのを無駄にする必要はありません。
匿名ユーザーに提供されるページ（すべての匿名ユーザーに同じページ）と識別されたユーザーに提供されるページ（「こんにちは、Xさん、新しいメッセージがあります」など）には違いがあるのではないでしょうか。
- その場合、匿名ユーザーに提供されるページをキャッシュするようにリバースプロキシを構成できます（通常、セッションCookieなどのCookieに基づいて）
- これは、Apache + PHPが処理する必要が少ないことを意味します。つまり、識別されたユーザーのみです。これは、ユーザーのごく一部にすぎない可能性があります。

リバースプロキシをキャッシュとして使用することについて、PHPアプリケーションの場合、たとえば、ベンチマーク結果でAPCとSquidキャッシュを使用したサーバー機能の400％〜700％の増加を確認できます。
（はい、彼らはSquidを使用しています、そして私はワニスについて話していました-それはちょうど別の可能性です^^ワニスはより最近ですが、よりキャッシングに専念しています）

それを十分に行い、何度も何度もページの再生成を停止することができれば、コードを最適化する必要さえ
ないかもしれません;-) 少なくとも、急いでいないかもしれません...そして、あまり圧力がかかっていないときに最適化を実行することをお勧めします...

補足として：あなたはOPで言っています：

私がコハナで作ったサイトは昨日大量のトラフィックで非難されました、

これは、Webサイトが秒単位で最新でないことに対処できる場合、リバースプロキシが文字通りその日を節約できるような突然の状況です。

それをインストールし、構成し、常に-毎日-実行させます：
- PHPページをキャッシュに保持しないように構成します。または短期間のみ。このようにして、常に最新のデータを表示できます
そして、あなたがスラッシュドット効果またはディグ効果をとる日：
- PHPページをキャッシュに保持するようにリバースプロキシを構成します。または長期間; たぶんあなたのページは秒単位で最新ではないでしょう、しかしそれはあなたのウェブサイトがディグ効果を生き残ることを可能にするでしょう！

それについて、どうすれば「スラッシュドット」であることを検出して生き残ることができますか？興味深い読み物かもしれません。

PHP側では：

まず第一に：あなたはPHPの最新バージョンを使用していますか？新しいバージョンでは、速度が定期的に改善されています;-)
たとえば、PHP Branches3.0から5.3-CVSのベンチマークを見てください。

パフォーマンスがPHP5.3を使用する非常に良い理由であることに注意してください（私はいくつかのベンチマークを（フランス語で）作成しました、そして結果は素晴らしいです） ...もちろん、PHP5.2が寿命に達したというもう1つのかなり良い理由です
、そしてもう維持されていません！

オペコードキャッシュを使用していますか？

私はAPCについて考えています-たとえば、代替PHPキャッシュ（pecl、manual）、これは私が最も使用しているのを見たソリューションです-そしてそれは私が働いたすべてのサーバーで使用されています。
- 参照：スライドAPC Facebook、
- またはベンチマークの結果は、APCとSquidキャッシュでサーバー機能が400％〜700％増加することを示しています。
場合によっては、サーバーのCPU負荷を大幅に下げることができます（APCをインストールしてそのオペコードキャッシュ機能をアクティブ化するだけで、一部のサーバーのCPU負荷が80％から40％になるのを見てきました！）
基本的に、PHPスクリプトの実行は2つのステップで行われます。
- PHPソースコードのオペコードへのコンパイル（JAVAのバイトコードに相当するもの）
- それらのオペコードの実行
- APCはそれらをメモリに保持するため、PHPスクリプト/ファイルが実行されるたびに実行する作業が少なくなります。RAMからオペコードをフェッチして実行するだけです。
ちなみに、 APCの構成オプションを確認する必要があるかもしれません
- それらのかなりの数があり、いくつかはあなたの速度/ CPU負荷/使いやすさの両方に大きな影響を与える可能性があります
- たとえば、無効にする[apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat)ことはシステムの負荷に適しています。ただし、オペコードキャッシュ全体をフラッシュしない限り、PHPファイルに加えられた変更は考慮されません。それについては、たとえば、To stat（）またはNot To stat（）を参照してください。

データにキャッシュを使用する

可能な限り、同じことを何度も繰り返すことは避けたほうがよいでしょう。ます。

私が考えている主なことは、もちろん、SQLクエリです。ページの多くはおそらく同じクエリを実行し、それらのいくつかの結果はおそらくほとんど常に同じです...つまり、多くの「役に立たない」クエリを意味しますデータベースに対して作成され、同じデータを何度も何度も提供するために時間を費やす必要があります。
もちろん、これは、Webサービスの呼び出し、他のWebサイトからの情報の取得、大量の計算など、他のものにも当てはまります...

あなたが特定することは非常に興味深いかもしれません：

どのクエリが何度も実行され、常に同じデータが返されるか
他のどの（重い）計算が多くの時間行われ、常に同じ結果を返すか

そして、これらのデータ/結果をある種のキャッシュに保存するので、取得がより簡単になります-より速く、「何もしない」ためにSQLサーバーにアクセスする必要がなくなります。

優れたキャッシュメカニズムは、たとえば次のとおりです。

APC：前に説明したオペコードキャッシュに加えて、データをメモリに保存できます。
および/またはmemcached （も参照）。これは、文字通り大量のデータがある場合や複数のサーバーを使用している場合に非常に便利です。、分散されているため。
もちろん、ファイルについて考えることもできます。そしておそらく他の多くのアイデア。

あなたのフレームワークにはキャッシュ関連のものがいくつか付属していると確信しています。OPで「今後、キャッシュライブラリをもっと使用する」と言ったように、おそらくすでにご存知でしょう;-)

プロファイリング

ここで、Xdebug拡張機能を使用してアプリケーションのプロファイルを作成することをお勧めします。これにより、多くの場合、非常に簡単にいくつかの弱点を見つけることができます。少なくとも、時間がかかる関数がある場合はそうです。

適切に構成すると、次のようないくつかのグラフィックツールで分析できるプロファイリングファイルが生成されます。

KCachegrind：私のお気に入りですが、Linux / KDEでのみ動作します
Windows用のWincachegrind ; 残念ながら、KCacheGrindよりも機能が少し少なくなります。通常、callgraphは表示されません。
PHP Webサーバー上で実行されるWebgrindは、どこでも機能しますが、おそらく機能が少なくなります。

たとえば、KCacheGrindのスクリーンショットをいくつか示します。

_{（出典：pascal-martin.fr）}_（出典：_{pascal-martin.fr}_）

（ところで、2番目のスクリーンショットに表示されているコールグラフは、私が正しく覚えていれば、通常、WinCacheGrindもWebgrindも実行できないものです^^）

（コメントありがとう@Mikushi）私があまり使っていないもう一つの可能性はxhprofです拡張機能です：それはプロファイリングにも役立ち、callgraphsを生成できます-しかしXdebugよりも軽いので、それをインストールできるはずです本番サーバー。

XHGuiと一緒に使用できるはずです。これは、データの視覚化に役立ちます。

SQL側では：

PHPについて少しお話ししたので、ボトルネックがPHP側ではなく、データベース側である可能性が高いことに注意してください...

ここに少なくとも2つまたは3つのことがあります：

次のことを決定する必要があります。
- アプリケーションが実行している最も頻繁なクエリは何ですか
- MySQLを使用している場合は、命令を使用して、それらが最適化されているかどうか（主に適切なインデックスを使用していますか？）EXPLAIN
  - 参照：SELECTおよびその他のステートメントの最適化
  - たとえば、アクティブ化log_slow_queriesして「時間がかかりすぎる」リクエストのリストを取得し、それらによって最適化を開始できます。
- これらのクエリのいくつかをキャッシュできるかどうか（前に言ったことを参照）
MySQLは適切に構成されていますか？それについてはよくわかりませんが、影響を与える可能性のある構成オプションがいくつかあります。
- MySQL Serverを最適化すると、それに関する興味深い情報が得られる場合があります。

それでも、2つの最も重要なことは次のとおりです。

必要がない場合は、DBに移動しないでください。できるだけ多くのキャッシュを作成してください。
DBに移動する必要がある場合は、効率的なクエリを使用します。インデックスを使用します。とプロフィール！

そして今何？

あなたがまだ読んでいるなら、他に何を最適化することができますか？

まあ、まだ改善の余地があります...アーキテクチャ指向のアイデアがいくつかあります：

n層アーキテクチャに切り替えます。
- MySQLを別のサーバーに配置します（2層：1つはPHP用、もう1つはMySQL用）
- 複数のPHPサーバーを使用します（そしてそれらの間でユーザーの負荷を分散します）
- 次のような軽量のWebサーバーを使用して、静的ファイルに別のマシンを使用します。
  - lighttpd
  - またはnginx-これはますます人気が高まっています、ところで。
- MySQLには複数のサーバー、PHPには複数のサーバー、およびそれらの前にいくつかのリバースプロキシを使用します
- もちろん、memcachedデーモンを任意の量の空きRAMがあるサーバーにインストールし、それらを使用して、できるだけ多くのキャッシュを作成します。
Apacheよりも「より効率的な」ものを使用しますか？
- 私はnginxについてますますよく耳にします。nginxはPHPや大量のWebサイトに関しては素晴らしいと思われます。私自身は使ったことがありませんが、ネット上で興味深い記事を見つけるかもしれません。
  - たとえば、PHPパフォーマンスIII-nginxの実行。
  - 参照：PHP-FPM-FastCGI Process Manager、これはPHP> = 5.3.3にバンドルされており、nginxで驚異的です。

ええと、それらのアイデアのいくつかはあなたの状況では少しやり過ぎかもしれません^^
しかし、それでも...念のために、それらを少し勉強してみませんか？;-)

そして、コハナはどうですか？

あなたの最初の質問は、コハナを使用するアプリケーションの最適化についてでした...まあ、私はすべてのPHPアプリケーションに当てはまるいくつかのアイデアを投稿しました...つまり、コハナにも当てはまります
;-）（それに固有ではないにしても^^）

私は言った：キャッシュを使用する。コハナはいくつかのキャッシングをサポートしているようです（あなたはそれについて自分で話したので、ここ
では何も新しいことはありません...）すぐにできることがあれば、試してみてください;-)

また、必要のないことは何もしてはいけないと言いました。コハナでデフォルトで有効になっている必要のないものはありますか？
ネットを閲覧すると、XSSフィルタリングについて少なくとも何かがあるようです。あなたはそれが必要ですか？

それでも、役立つ可能性のあるリンクがいくつかあります。

結論？

そして、結論として、簡単な考え：

あなたの会社があなたに5日間支払うのにどれくらいの費用がかかりますか？ -いくつかの優れた最適化を行うのに妥当な時間であることを考慮すると
あなたの会社が2台目のサーバーとそのメンテナンスを購入（支払い）するのにどれくらいの費用がかかりますか？
より大きくスケーリングする必要がある場合はどうなりますか？
- 10日を費やすのにどれくらいの費用がかかりますか？もっと？アプリケーションのすべての可能なビットを最適化しますか？
- そして、さらに2、3台のサーバーでいくらですか？

私はあなたが最適化すべきではないと言っているのではありません：あなたは間違いなくすべきです！
ただし、最初に大きな見返りが得られる「迅速な」最適化を行ってください。オペコードキャッシュを使用すると、サーバーのCPU負荷を10〜50％削減できる可能性があります...セットアップには数分しかかかりません;- ）反対側では、2％で3日を費やしています...

ああ、そして、ところで：何かをする前に：いくつかの監視機能を配置して、どのような改善が行われたか、そしてどのように行われたかを知ってください！
監視しなければ、あなたはあなたがしたことの効果を知ることができません...それが本当の最適化であるかどうかにかかわらず！

たとえば、RRDtool + cactiのようなものを使用できます。
そして、CPU負荷が40％低下した素晴らしいグラフィックを上司に見せることは、常に素晴らしいことです;-)

とにかく、そして本当に結論として：楽しんでください！
（はい、最適化は楽しいです！）
（ええと、私はそれほど多くを書くとは思いませんでした...これの少なくともいくつかの部分が役立つことを願っています...そして私はこの答えを覚えておくべきです：他の時に役立つかもしれません。 ..）

Question 3

XDebugとWinCacheGrindまたはWebCacheGrindを使用して、スローコードの実行をプロファイリングおよび分析します。

_{（ソース：jokke.dk）}
WinCacheGrind

Question 4

XDebugを使用したプロファイルコード。

多くのキャッシュを使用します。ページが比較的静的である場合は、リバースプロキシが最善の方法である可能性があります。

Question 5

コハナは、データベースオブジェクトの使用を除いて、非常に高速にすぐに使用できます。Zomborの言葉を引用すると、「結果配列の代わりにデータベース結果オブジェクトを使用していることを確認することで、メモリ使用量を減らすことができます。」これにより、非難されているサイトでHUGEEのパフォーマンスに違いが生じます。より多くのメモリを使用するだけでなく、スクリプトの実行が遅くなります。

また、キャッシュを使用する必要があります。私はmemcacheを好み、次のようにモデルで使用します。

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

これにより、パフォーマンスも劇的に向上します。上記の2つの手法により、サイトのパフォーマンスが80％向上しました。

ボトルネックがどこにあると思うかについてもう少し情報を提供していただければ、より良いアイデアを提供できると確信しています。

他のパフォーマンスのヒントについては、yslow（google it）もチェックしてください。

Question 6

コハナと厳密に関連している（おそらくすでにこれを行っているかどうか）：

本番モードの場合：

内部キャッシュを有効にします（これにより、Kohana :: find_fileの結果のみがキャッシュされますが、実際には非常に役立ちます。
プロファイラーを無効にする

ちょうど私の2セント:)

Question 7

XDebugとキャッシュの回答に完全に同意します。最大の速度とスケールのボトルネックを特定するまで、最適化のためにコハナレイヤーを調べないでください。

XDebugは、ほとんどの時間を費やしたことを通知し、コード内の「ホットスポット」を識別します。このプロファイリング情報を保持して、パフォーマンスの向上をベースライン化して測定できるようにします。

問題と解決策の例：データベースから毎回高価なオブジェクトを構築していて、それが実際には頻繁に変更されないことがわかった場合は、memcachedまたは別のメカニズムを使用してそれらをキャッシュすることを検討できます。これらのパフォーマンス修正はすべて時間がかかり、システムが複雑になるため、修正を開始する前にボトルネックを確認してください。