php/yii2
1
0
Fork 0
mirror of https://github.com/yiisoft/yii2.git synced 2025-11-03 22:32:40 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6816 from softark/docs-guide-ja-tutorial-performance

Browse Source 
docs/guide-ja/tutorial-performance-tuning.md - added [ci skip]
This commit is contained in:
Alexander Makarov
2015-01-10 21:28:24 +08:00
parent f638f429b7 1c68269384
commit dd380e5e39
3 changed files with 348 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/guide-ja/README.md
View File

@ -167,8 +167,8 @@ RESTful ウェブサービス
* [コアバリデータ](tutorial-core-validators.md)
* [国際化](tutorial-i18n.md)
* [メール送信](tutorial-mailing.md)
* **翻訳中** [パフォーマンスチューニング](tutorial-performance-tuning.md)
* **翻訳中** [共有ホスト環境](tutorial-shared-hosting.md)
* [パフォーマンスチューニング](tutorial-performance-tuning.md)
* [共有ホスティング環境](tutorial-shared-hosting.md)
* **翻訳中** [テンプレートエンジン](tutorial-template-engines.md)
* **翻訳中** [サードパーティのコードを扱う](tutorial-yii-integration.md)

230
docs/guide-ja/tutorial-performance-tuning.md Normal file
View File

@ -0,0 +1,230 @@
パフォーマンスチューニング
==========================
> Note|注意: この節はまだ執筆中です。
あなたのウェブアプリケーションのパフォーマンスは二つの部分に基づいています。
一つはフレームワークのパフォーマンスであり、もう一つはアプリケーションそのものです。
Yii は、そのままの状態でも、あなたのアプリケーションのパフォーマンスを劣化させる影響がかなり小さいものですが、本番環境のためには、さらに微調整することが可能です。
アプリケーションに関しては、ベストプラクティスのいくつかを提供すると共に、それを Yii に適用する方法を例示します。
環境を準備する
--------------
PHP アプリケーションを走らせるための環境を正しく構成することは本当に重要です。
最大のパフォーマンスを得るためには、
- 常に最新の安定した PHP バージョンを使うこと。
PHP は、メジャーリリースのたびに、顕著なパフォーマンスの改善とメモリ使用の削減がなされています。
- PHP 5.4 以下には [APC](http://ru2.php.net/apc)、または、PHP 5.5 以上には [Opcache](http://php.net/opcache) を使うこと。
このことは、非常に良いパフォーマンス強化をもたらします。
フレームワークを本番用に準備する
--------------------------------
### デバッグモードを無効化する
アプリケーションを本番環境に配備する前に行うべき最初のことは、デバッグモードの無効化です。
Yii のアプリケーションは、`index.php` において定数 `YII_DEBUG` が `true` と定義されていると、デバッグモードで走ります。
従って、デバッグモードを無効にするために、以下のコードが `index.php` になければなりません。
```php
defined('YII_DEBUG') or define('YII_DEBUG', false);
```
デバッグモードは開発段階において非常に役に立ちますが、いくつかのコンポーネントがデバッグモードにおいて追加の負荷を発生させるため、パフォーマンスを劣化させます。
例えば、メッセージロガーは、ログに記録されるすべてのメッセージについて、追加のデバッグ情報を記録します。
### PHP opcode キャッシュを有効にする
PHP opcode キャッシュを有効にすると、すべての PHP アプリケーションで、顕著にパフォーマンスが向上し、メモリ使用量が削減されます。
Yii も例外ではありません。
[PHP 5.5 OPcache](http://php.net/manual/ja/book.opcache.php) と [APC PHP 拡張](http://php.net/manual/ja/book.apc.php) の両方でテストされています。
どちらのキャッシュも、PHP 中間コードを最適化して、入ってくるリクエストごとに PHP スクリプトを解析するために時間を消費することを回避します。
### ActiveRecord のデータベーススキーマキャッシュを有効にする
アプリケーションがアクティブレコードを使用している場合は、スキーマキャッシュを有効にして、データベーススキーマを解析するための時間を節約すべきです。
そうするためには、アプリケーションの構成情報 `config/web.php` において、`Connection::enableSchemaCache` プロパティを `true` に設定します。
```php
return [
// ...
'components' => [
// ...
'db' => [
'class' => 'yii\db\Connection',
'dsn' => 'mysql:host=localhost;dbname=mydatabase',
'username' => 'root',
'password' => '',
'enableSchemaCache' => true,
// スキーマキャッシュの持続時間
// 'schemaCacheDuration' => 3600,
// 使用されるキャッシュコンポーネントの名前。デフォルトは 'cache'。
//'schemaCache' => 'cache',
],
'cache' => [
'class' => 'yii\caching\FileCache',
],
],
];
```
`cache` [アプリケーションコンポーネント](structure-application-components.md) が構成されていなければならないことに注意してください。
### アセットを結合して最小化する
アセットは、典型的には JavaScript と CSS ですが、結合して圧縮することが出来ます。
これにより、ページの読み込みにかかる時間をわずかながら削減して、アプリケーションのエンドユーザにより良いユーザ体験をもたらすことが出来ます。
これをどのようにすれば達成できるかについて学ぶためには、ガイドの [アセット](structure-assets.md) の節を参照してください。
### セッションのためにより良いストレージを使用する
デフォルトでは、PHP はセッションを処理するためにファイルを使います。
開発と小さなプロジェクトではそれでも構いませんが、リクエストを並列処理するとなると、データベースのような別のストレージに変更する方が良いでしょう。
そうするためには、`config/web.php` によってアプリケーションを構成します。
```php
return [
// ...
'components' => [
'session' => [
'class' => 'yii\web\DbSession',
// デフォルトの 'db' 以外の DB コンポーネントを使用したい場合は
// 以下を設定する
// 'db' => 'mydb',
// デフォルトの session テーブルをオーバーライドするためには
// 以下を設定する
// 'sessionTable' => 'my_session',
],
],
];
```
`CacheSession` を使って、セッションをキャッシュに保存することが出来ます。
キャッシュストレージの中には、memcached のように、セッションデータが失われないことを保証しないものもあり、予期せぬログアウトを引き起こす場合があることに注意してください。
サーバに [Redis](http://redis.io/) がある場合は、それをセッションのストレージに使用することを強く推奨します。
アプリケーションを改善する
--------------------------
### サーバ側のキャッシュテクニックを使う
キャッシュの節で説明されているように、Yii はウェブアプリケーションのパフォーマンスを著しく改善することが出来るキャッシュのソリューションをいくつか提供しています。
データの生成に長い時間を要するものがある場合は、データキャッシュの手法を使用して、データを生成する頻度を削減することが出来ます。
ページのある部分が比較的静的なものであり続ける場合は、フラグメントキャッシュの手法を使用して、その部分のレンダリングの頻度を削減することが出来ます。
あるページ全体が比較的静的なものであり続ける場合は、ページキャッシュの手法を使用して、ページ全体のレンダリングのコストを節約することが出来ます。
### HTTP キャッシュを利用して、処理時間と帯域を節約する
HTTP キャッシュを利用すると、処理時間および帯域やリソースを著しく節約することが出来ます。
HTTP キャッシュは、`ETag` または `Last-Modified` ヘッダをアプリケーションのレスポンスで送信することによって実装することが出来ます。
ブラウザが HTTP の仕様に従って実装されていれば (ほとんどのブラウザがそうです)、コンテントは以前の状態と異なる場合にだけ取得されます。
正しいヘッダを作成することは手間のかかる仕事ですので、Yii は [[yii\filters\HttpCache]] というコントローラフィルタの形でショートカットを提供しています。
これを使うことはとても簡単です。
コントローラの中で `behaviors` メソッドを以下のように実装することが必要です。
```php
public function behaviors()
{
return [
'httpCache' => [
'class' => \yii\filters\HttpCache::className(),
'only' => ['list'],
'lastModified' => function ($action, $params) {
$q = new Query();
return strtotime($q->from('users')->max('updated_timestamp'));
},
// 'etagSeed' => function ($action, $params) {
// return // egat のシードをここで生成
//}
],
];
}
```
上記のコードでは、`etagSeed` または `lastModified` のどちらかを使うことが出来ます。
両方を実装する必要はありません。
目的は、コンテントを取得してレンダリングするよりも安価な方法を使って、コンテントが修正されたかどうかを判断することです。
`lastModified` はコンテントが最後に修正されたときの UNIX タイムスタンプを返さなければなりません。
一方 `etagSeed` は `ETag` ヘッダの値を生成するために使われる文字列を返さなければなりません。
### データベースの最適化
データベースからのデータ取得がウェブアプリケーションのパフォーマンスの主たるボトルネックになることがよくあります。
[キャッシュ](caching.md#Query-Caching) の使用によってパフォーマンスの劣化を緩和することは出来ますが、問題を完全に解決することは出来ません。
データベースが膨大なデータを抱えている場合、キャッシュされたデータが無効化されたときに最新のデータを取得するためのコストは、データベースとクエリが適切に設計されていないと、法外なものになり得ます。
データベースのインデックスを上手に設計しましょう。
インデックスを付けると SELECT クエリを非常に速くすることが出来ます。ただし、INSERT、UPDATE、または DELTE のクエリは遅くなることがあります。
複雑なクエリに対しては、PHP コードの中からクエリを発行して DBMS にクエリを解析するように繰り返して求める代わりに、データベースビューを作成することを推奨します。
アクティブレコードを使い過ぎないでください。
アクティブレコード は OOP 流にデータをモデリングするには便利ですが、クエリ結果の各行を表すために一つまたは複数のオブジェクトを作る必要があるため、パフォーマンスを現実に低下させます。
膨大なデータを扱うアプリケーションでは、より低レベルの DAO や データベース API を使うのが良い選択でしょう。
最後にもう一つ大事なことですが、SELECT クエリで LIMIT を使ってください。
こうすることで、大量のデータが返されて、PHP のために確保されたメモリを使い尽くすということがなくなります。
### asArray を使う
読み出し専用のページにおいて、メモリと処理時間を節約する良い方法に、アクティブレコードの `asArray` メソッドを使うという方法があります。
```php
class PostController extends Controller
{
public function actionIndex()
{
$posts = Post::find()->orderBy('id DESC')->limit(100)->asArray()->all();
return $this->render('index', ['posts' => $posts]);
}
}
```
ビューにおいては、`$posts` の個々のレコードのフィールドを配列としてアクセスしなければなりません。
```php
foreach ($posts as $post) {
echo $post['title'] . "<br>";
}
```
`asArray` が指定されていなくても配列記法を使用してフィールドにアクセスすることが出来ますが、その場合は AR オブジェクトを扱っていることに注意してください。
### バックグラウンドでデータを処理する
ユーザのリクエストに素早く応答したい場合、リクエストの重い部分は、それについて即座にレスポンスを返す必要がなければ、後から処理することが出来ます。
これを達成する一般的な方法が二つあります。クロンジョブによる処理と、専用のキューです。
最初のケースでは、後から処理したいデータを、データベースなどの持続的ストレージに保存する必要があります。
そして、クロンジョブによって定期的に実行される [コンソールコマンド](tutorial-console.md) がデータベースを検索して、データがあれば処理します。
このソリューションでたいていの場合は OK ですが、一つ大きな欠点があります。
データベースを検索するまでは処理すべきデータの有無を知ることが出来ません。
そのため、データベースをかなり頻繁に検索するか、または、各処理の間に若干の遅延を生じさせるかのどちらかになります。
この問題は、キューやジョブサーバ (RabbitMQ、ActiveMQ、Amazon SQS、その他いろいろ) によって解決することが出来ます。
この場合は、持続的ストレージにデータを書き込む代りに、キューやジョブサーバによって提供される API を通じてデータをキューに入れます。
処理はたいていはジョブハンドラのクラスに渡されます。
キューに入れられたジョブは、先行するジョブが全て完了した直後に実行されます。
### 何をしても効果がない場合
何をしても効果がない場合は、何がパフォーマンスの問題を解決するかについての思い込みを排することです。
代りに、何でも変更する前には、常にコードをプロファイルにかけてください。
次のツールが役に立つでしょう。
- [Yii のデバッグツールバーとデバッガ](tool-debugger.md)
- [XDebug プロファイラ](http://xdebug.org/docs/profiler)
- [XHProf](http://www.php.net/manual/en/book.xhprof.php)

116
docs/guide-ja/tutorial-shared-hosting.md Normal file
View File

@ -0,0 +1,116 @@
共有ホスティング環境
====================
共有ホスティング環境では、たいてい、構成やディレクトリ構造について、大きな制約があります。
それでも、ほとんどの場合、Yii 2.0 を共有ホスティング環境で走らせることは可能です。
ベーシックアプリケーションを配備する
------------------------------------
通例、一つのウェブルートしかありませんので、ベーシックアプリケーションテンプレートを使用することを推奨します。
[Yii をインストールする](start-installation.md) の節を参照して、アプリケーションテンプレートをローカル環境にインストールしてください。
### ウェブサーバのための追加設定 <a name="add-extras-for-webserver"></a>
使用されているウェブサーバが Apache である場合は、次の内容を持つ `.htaccess` ファイルを `web` (`index.php` があるディレクトリ) に追加する必要があります。
```
Options +FollowSymLinks
IndexIgnore */*
RewriteEngine on
# ディレクトリかファイルが存在すれば、それを直接使う
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# それ以外は、index.php にフォワードする
RewriteRule . index.php
```
nginx の場合は、追加の構成ファイルは必要がない筈です。
### ウェブルートの名前を変える <a name="renaming-webroot"></a>
FTP またはその他の手段であなたの共有ホストに接続したとき、下記のようなディレクトリが見えれば、あなたはきっとラッキーです。
```
config
logs
www
```
上記で `www` はウェブサーバのディレクトリルート (すなわち、ウェブルート) です。
別の名前かもしれません。よくある名前は、`www`、`htdocs`、`public_html` です。
ベーシックアプリケーションテンプレートではウェブルートの名前は `web` になっていますので、アップロードする前に、これをホストのウェブルートの名前に変更する必要があります。
### FTP ルートディレクトリは書き込み可能とする
ルートレベルのディレクトリ、すなわち、`config`、`logs`、`www` があるディレクトリに対して書き込みが出来るのであれば、`assets`、`commands` などをそのままアップロードします。
### 必要条件をチェックする
Yii を走らせるためには、ホストは Yii の必要条件を満たさなければなりません。
最低限の必要条件は PHP 5.4 です。
残りの条件をチェックするために、`requirements.php` をルートディレクトリからウェブルートディレクトリにコピーして、`http://example.com/requirements.php` という URL を使ってブラウザ経由で走らせます。
後でファイルを削除するのを忘れないでください。
アドバンストアプリケーションを配備する
--------------------------------------
アドバンストアプリケーションを共有ホストに配備するのは、ベーシックアプリケーションを配備するのに比べると、少しトリッキーになります。
なぜなら、アドバンストアプリケーションは、共有ホストが通常は持っていない二つのウェブルートを持つからです。
このため、構造を少し修正します。
### エントリスクリプトを単一のウェブルートに移動する
まずは、単一のウェブルートディレクトリが必要です。
上記の [ウェブルートの名前を変える](#renaming-webroot) で説明したように、あなたのホストのウェブルートに合うように名前を付けてください。
次に、以下のような構造を作成します。
```
www
admin
backend
common
console
environments
frontend
...
```
`www` がフロントエンドディレクトリになりますので、`frontend/web` の内容をそこに移動します。
同じように、`backend/web` の内容を `www/admin` に移動します。
どちらの場合も、`index.php` および `index-test.php` の中のパスを修正する必要があります。
### セッションとクッキーを分離する
元来は、バックエンドとフロントエンドは異なるドメインで走ることを意図されています。
両方を同じドメインに移動すると、二つが同じクッキーを共有して干渉することになります。
これを修正するために、バックエンドのアプリケーション構成 `backend/config/main.php` を以下のように修正します。
```php
'components' => [
'request' => [
'csrfParam' => '_backendCSRF',
'csrfCookie' => [
'httpOnly' => true,
'path' => '/admin',
],
],
'user' => [
'identityCookie' => [
'name' => '_backendIdentity',
'path' => '/admin',
'httpOnly' => true,
],
],
'session' => [
'name' => 'BACKENDSESSID',
'cookieParams' => [
'path' => '/admin',
],
],
],
```