|
|
|
|
@ -1,12 +1,10 @@
|
|
|
|
|
パフォーマンスチューニング |
|
|
|
|
========================== |
|
|
|
|
|
|
|
|
|
> Note|注意: この節はまだ執筆中です。 |
|
|
|
|
|
|
|
|
|
あなたのウェブアプリケーションのパフォーマンスは二つの部分に基づいています。 |
|
|
|
|
一つはフレームワークのパフォーマンスであり、もう一つはアプリケーションそのものです。 |
|
|
|
|
Yii は、そのままの状態でも、パフォーマンスを劣化させる影響がかなり小さいものですが、本番環境のためには、さらに微調整することが可能です。 |
|
|
|
|
アプリケーションに関しては、ベストプラクティスのいくつかを提供すると共に、それを Yii に適用する方法を例示します。 |
|
|
|
|
あなたのウェブアプリケーションのパフォーマンスに影響を及ぼす要因は数多くあります。 |
|
|
|
|
環境の要因もありますし、あなたのコードに関係する要因もあります。 |
|
|
|
|
また、Yii そのものに関係する要因もあります。 |
|
|
|
|
この節では要因のほとんどを列挙して、どのようにそれらを修正すればあなたのアプリケーションのパフォーマンスを向上させることが出来るかを説明します。 |
|
|
|
|
|
|
|
|
|
## PHP 環境を最適化する <span id="optimizing-php"></span> |
|
|
|
|
|
|
|
|
|
@ -81,11 +79,13 @@ HTTP リクエストの回数、および、これらのアセットの全体と
|
|
|
|
|
これによって、ページのロードにかかる時間とサーバの負荷を大きく削減することが出来ます。 |
|
|
|
|
詳細については、[アセット](structure-assets.md) の節を参照してください。 |
|
|
|
|
|
|
|
|
|
## セッションのためにより良いストレージを使用する |
|
|
|
|
## セッションのストレージを最適化する <span id="optimizing-session"></span> |
|
|
|
|
|
|
|
|
|
デフォルトでは、PHP はセッションを処理するためにファイルを使います。 |
|
|
|
|
開発と小さなプロジェクトではそれでも構いませんが、リクエストを並列処理するとなると、データベースのような別のストレージに変更する方が良いでしょう。 |
|
|
|
|
そうするためには、`config/web.php` によってアプリケーションを構成します。 |
|
|
|
|
デフォルトでは、セッションのデータはファイルに保存されます。 |
|
|
|
|
開発と小さなプロジェクトではそれでも構いません。 |
|
|
|
|
しかし、大量のリクエストを並列処理するとなると、データベースのような、もっと洗練されたストレージを使う方が良いでしょう。 |
|
|
|
|
Yii はさまざまなセッションストレージのサポートを内蔵しています。 |
|
|
|
|
これらのストレージは、[アプリケーションの構成情報](concept-configurations.md) の中で `session` コンポーネントを次のように構成することによって使用することが出来ます。 |
|
|
|
|
|
|
|
|
|
```php |
|
|
|
|
return [ |
|
|
|
|
@ -106,10 +106,24 @@ return [
|
|
|
|
|
]; |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
`CacheSession` を使って、セッションをキャッシュに保存することが出来ます。 |
|
|
|
|
キャッシュストレージの中には、memcached のように、セッションデータが失われないことを保証しないものもあり、予期せぬログアウトを引き起こす場合があることに注意してください。 |
|
|
|
|
上記の構成は、セッションデータの保存にデータベーステーブルを使用するものです。 |
|
|
|
|
デフォルトでは、`db` アプリケーションコンポーネントをデータベース接続として使用し、セッションデータを `session` テーブルに保存します。 |
|
|
|
|
ただし、前もって `session` テーブルを次のように作っておく必要があります。 |
|
|
|
|
|
|
|
|
|
```sql |
|
|
|
|
CREATE TABLE session ( |
|
|
|
|
id CHAR(40) NOT NULL PRIMARY KEY, |
|
|
|
|
expire INTEGER, |
|
|
|
|
data BLOB |
|
|
|
|
) |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
[[yii\web\CacheSession]] を使って、セッションをキャッシュに保存することも出来ます。 |
|
|
|
|
理論上、サポートされている [キャッシュストレージ](caching-data.md#supported-cache-storage) のどれでも使うことが出来ます。 |
|
|
|
|
ただし、キャッシュストレージの中には、容量の上限に達したときにキャッシュされたデータをフラッシュするものがあることに注意してください。 |
|
|
|
|
この理由により、主として容量の上限が無い種類のキャッシュストレージを使用すべきです。 |
|
|
|
|
|
|
|
|
|
サーバに [Redis](http://redis.io/) がある場合は、それをセッションのストレージに使用することを強く推奨します。 |
|
|
|
|
あなたのサーバに [Redis](http://redis.io/) がある場合は、[[yii\redis\Session]] によって redis をセッションストレージとして使用することを強く推奨します。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## データベースを最適化する <span id="optimizing-databases"></span> |
|
|
|
|
@ -150,33 +164,35 @@ class PostController extends Controller
|
|
|
|
|
クエリを構築するのに [DAO](db-dao.md) を使って、データをプレーンな配列に取得することも出来ます。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Composer オートローダを最適化する |
|
|
|
|
## Composer オートローダを最適化する <span id="optimizing-autoloader"></span> |
|
|
|
|
|
|
|
|
|
全体としてのパフォーマンスを改善するために、`composer dumpautoload -o` を実行して、Composer のオートローダを最適化することが出来ます。 |
|
|
|
|
Composer のオートローダは、ほとんどのサードパーティのクラスファイルをインクルードするのに使われますので、次のコマンドを実行して Composer のオートローダを最適化することを考慮すべきです。 |
|
|
|
|
|
|
|
|
|
``` |
|
|
|
|
composer dumpautoload -o |
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
## バックグラウンドでデータを処理する |
|
|
|
|
## オフラインでデータを処理する <span id="processing-data-offline"></span> |
|
|
|
|
|
|
|
|
|
ユーザのリクエストに素早く応答したい場合、リクエストの重い部分は、それについて即座にレスポンスを返す必要がなければ、後から処理することが出来ます。 |
|
|
|
|
リクエストが何らかのリソース集約的な操作を必要とするものである場合は、そういう操作が終るまでユーザを待たせずに、オフラインモードで操作を実行する方策を考えるべきです。 |
|
|
|
|
|
|
|
|
|
これを達成する一般的な方法が二つあります。クロンジョブによる処理と、専用のキューです。 |
|
|
|
|
オフラインでデータを処理するための方法が二つあります。 |
|
|
|
|
すなわち、プルとプッシュです。 |
|
|
|
|
|
|
|
|
|
最初のケースでは、後から処理したいデータを、データベースなどの持続的ストレージに保存する必要があります。 |
|
|
|
|
そして、クロンジョブによって定期的に実行される [コンソールコマンド](tutorial-console.md) がデータベースを検索して、データがあれば処理します。 |
|
|
|
|
プルの方法では、リクエストが何らかの複雑な操作を必要とするたびに、タスクを作成してデータベースなどの持続的ストレージに保存します。 |
|
|
|
|
そうしておいて、別の独立したプロセス (例えばクロンジョブ) を使い、タスクを引き出して処理します。 |
|
|
|
|
この方法は、実装は容易ですが、いくつかの欠点があります。 |
|
|
|
|
例えば、タスクのプロセスはストレージから定期的にタスクを引き出さなければなりません。 |
|
|
|
|
引き出す間隔が長すぎると、タスクの処理に大きな遅延が生じます。しかし、間隔が短すぎると、オーバーヘッドが大きくなります。 |
|
|
|
|
|
|
|
|
|
このソリューションでたいていの場合は OK ですが、一つ大きな欠点があります。 |
|
|
|
|
データベースを検索するまでは処理すべきデータの有無を知ることが出来ません。 |
|
|
|
|
そのため、データベースをかなり頻繁に検索するか、または、データの作成と処理の間に若干の遅延を生じさせるかのどちらかになります。 |
|
|
|
|
プッシュの方法では、タスクを管理するのにメッセージキュー (例えば、RabbitMQ、ActiveMQ、Amazon SQS など) を使用します。 |
|
|
|
|
新しいタスクがキューに入れられるたびに、タスクを処理するプロセスが起動されたり通知を受けたりして、タスク処理がトリガされます。 |
|
|
|
|
|
|
|
|
|
この問題は、キューやジョブサーバ (RabbitMQ、ActiveMQ、Amazon SQS、その他いろいろ) によって解決することが出来ます。 |
|
|
|
|
この場合は、持続的ストレージにデータを書き込む代りに、キューやジョブサーバによって提供される API を通じてデータをキューに入れます。 |
|
|
|
|
処理はたいていはジョブハンドラのクラスに渡されます。 |
|
|
|
|
キューに入れられたジョブは、先行するジョブが全て完了した直後に実行されます。 |
|
|
|
|
|
|
|
|
|
## 何をしても効果がない場合 |
|
|
|
|
## パフォーマンスプロファイリング <span id="performance-profiling"></span> |
|
|
|
|
|
|
|
|
|
何をしても効果がない場合は、何がパフォーマンスの問題を解決するかについての思い込みを排することです。 |
|
|
|
|
代りに、いつでも、何かを変更する前にはコードをプロファイルしてください。 |
|
|
|
|
次のツールが役に立つでしょう。 |
|
|
|
|
あなたは、あなたのコードをプロファイルして、パフォーマンスのボトルネックを発見し、それに応じた適切な手段を講じるべきです。 |
|
|
|
|
次のプロファイリングツールが役に立つでしょう。 |
|
|
|
|
|
|
|
|
|
- [Yii のデバッグツールバーとデバッガ](https://github.com/yiisoft/yii2-debug/blob/master/docs/guide-ja/README.md) |
|
|
|
|
- [XDebug プロファイラ](http://xdebug.org/docs/profiler) |
|
|
|
|
|
Alexander Makarov
9 years ago