PHP パフォーマンス最適化百科事典 (php.ini)、パフォーマンス最適化 php.ini_PHP チュートリアル

PHPパフォーマンス最適化事典(php.ini)、パフォーマンス最適化php.ini

第1章 過剰なシステムコールの最適化
今回の最適化は、システムコール呼び出しが多すぎる問題を対象としているため、分析のために strace を使用して Apache を追跡します。

1.apache2ctl -X と
httpd プロセスを開始するには、-X (デバッグ) パラメーターを使用します。現時点では、httpd プロセスは 1 つだけ開始されます
。 2. ps -ef grep httpd
strace が必要な PID を見つけます
3. strace -p $PID -o /tmp/strace.log
http リクエストを httpd に送信すると、strace 情報が表示されます。

1. Include_path の問題

通常、この種の情報がたくさん表示されます:
stat64("/error/dir/test.php", 0xbfab4b9c) = -1 ENOENT (そのようなファイルまたはディレクトリはありません)
解決策:
1. アプリケーション php で include_path を設定し、「.」などの相対パスを削除し、より多くのファイルを含むディレクトリを先頭に置きます。 include_path を走査するときにすぐに見つかるようにしてください。
2. include、require、include_once、require_once には絶対パスを使用します
3. PHP の自動読み込みメカニズムを使用します

2. Apache の書き換え設定

コードをコピーします コードは次のとおりです:
リライトエンジンオン
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteRule .* %{DOCUMENT_ROOT}%/index.php
#RewriteRule .* /index.php

ここでコメントアウトされた最後の書き換え構成は、リクエストごとに 1 つ以上の syscall が発生するため、適切ではありません
stat64("/index.php", 0xbfab4b9c) = -1 ENOENT (そのようなファイルまたはディレクトリはありません)

3. Apache ログの問題
問題をテストしていたときに、カスタム ログにアクセス時間やその他の情報が記録されている場合、さらに多くの情報が記録されることがわかりました
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=165, ...}) = 0
大量のログが記録されると、パフォーマンスが非常に低下します。単純なアプリケーションの場合、複雑なログが記録されると、パフォーマンスが 30 倍低下します。
解決策:
haproxy や nginx などの複数の Apache フロントエンドに http 層プロキシを設定します。これらの場所にログを保管してください。アクセス レイヤの負荷は一般に高くないため、プロキシはある程度のロギング作業を行うことができます。この構成では、Apache のログをオフにすることができます。

4. Realpath() の問題
この記事をご覧ください: http://bugs.php.net/bug.php?id=43864
lstat64 が何度も呼び出されると、ホストの CPU と IO が比較的高くなります。
その理由は、php5.2.x が realpath() を十分に実装していないため、lstat64() がディレクトリ階層のレベルごとに呼び出されるからです。
この問題を解決するために、realpath_cache を使用して特定のファイルのリアルパスを保存します。ここにはリーフ ノードのリアルパスのみが保存されますが、パス上のコンテンツは保存されないため、「/a/b/c/d/e/f/g/a.php」リアルパス チェックを実行すると、lstat64 は次のようになります。 「/a/b/c /d/e/f/g/b.php」を確認する場合は、「/a/b/c/d/e/f/g/」も確認する必要があります。したがって、最適化の提案としては、「ディレクトリ レベルを下げるか、「/」ルート ディレクトリに置くことさえあります。もちろん、これはお勧めしません。5.3.0 以降、PHP は実装しています。上記の状況を例に挙げると、「/a/b/c/d/e/f/g/b.php」を確認すると、「b. php」にチェックが入っています。そのため、php5.3.0以降にアップグレードすると、この問題はうまく解決できます。
解決策: 1. include_once と require_once の使用はできるだけ少なくします
これら 2 つの関数は、シンボリック リンクによる繰り返しロードを防ぐためにリアルパス チェックを実行するためです。これらを使用しないと、リアルパスの呼び出しが減る可能性があります。
2. php.ini で realpath_cache_size および realpath_cache_ttl パラメータを適切に設定します
realpath_cache が使用されるため、サイズ制限が必要です。 Zend Framework など、多くのファイルを使用するプロジェクトの場合、デフォルトの realpath_cache_size=16k は小さすぎる可能性があります。この設定を 256K 以上に設定することをお勧めします。さらに、デフォルトの realpath_cache_ttl=120 は 2 分で期限切れになるため、3600 (1 時間) に設定する必要があります。
ここで注意する必要があるのは、この realpath_cache はすべての Apache プロセスに排他的であるため、大量のメモリを消費し、あまり大きく設定できないことです。
3. php5.3.x にアップグレードします
アプリケーションを詳細にテストし、問題がなければ、上位バージョンにアップグレードすることをお勧めします。


5.APCの使用 apc は php のオペコード コードをキャッシュできるため、通常はパフォーマンスが 30% 向上します。ただし、デフォルトの apc.stat=1 なので、各リクエストは、このファイルが更新されたかどうかを確認するために使用する必要がある php ファイルにアクセスし、php ファイルを再コンパイルするかどうかを決定します。これはパフォーマンスを非常に消費するため、オフにすることをお勧めします。
解決策:
1. apc.stat=0 を設定すると、リクエストするたびに必要な PHP ファイルにアクセスする必要がなくなります。
注意する必要があるのは、php ファイルを変更するバージョンを公開するたびに、apc_clear() を呼び出して apc キャッシュをクリアする必要があることです。そうしないと、コードが有効になりません。

6. スマートなチューニング 優れたモジュール性と多くのアプリケーションを備えた Web サイトの場合、smarty テンプレート システムを使用する場合、この時点で Smarty を調整する必要があります。そうしないと、smarty の部分に多額の費用がかかります。これまでの経験によると、smarty は経費の約 10% を占める可能性があります。
デフォルト設定では、smarty は各テンプレート ファイルが更新されたかどうかを検出し、テンプレート ファイルを再コンパイルするかどうかを決定します。テンプレートファイルが多い場合、stat システムコールも多くなり、コンテキストスイッチを使用するとオーバーヘッドが大きくなります。
解決策:
1. $smarty->compile_check = false;
各検出を削除しますが、その後は、バージョンをリリースするたびに、compile_dir ディレクトリ内のコンパイル済みテンプレートを削除する必要があります。削除しないと、テンプレート ファイルが有効になりません。
2. 可能であればキャッシュ機能を使用します。

結論
上記のチューニング後の結論は以下の通りです:
1. 上記の最適化を有効にするには、php5.3.1 にアップグレードします。これは、5.2.3 よりも 10% 以上優れています
2. 最適化された構成では、Zend Framework を使用して開発された検索アプリケーションは 1 秒あたり 210 リクエスト/rps に達します
3. 最適化された構成では、doophp フレームワークを使用して開発された検索アプリケーションは 1 秒あたり 450 リクエスト/rps に達します

第 2 章 APC キャッシュの使用

phpプログラムの実行処理
—》クライアント（ブラウザ）リクエスト hello.php を取得
—-》CGIサーバー（Apacheなど）はリクエストを受け取り、設定に従ってPHPハンドラー（mod_phpなど）を探します
—-》Apacheはphpハンドラーをロードし、phpハンドラーはphp.iniを読み込んでphp解釈環境を初期化します
—-》mod_php は hell.php を見つけてメモリにロードします
—-》mod_php はソースコードをオペコードツリーにコンパイルします
—-》mod_phpはオペコードツリーを実行します
——-》結果をブラウザに生成します

このプロセス中に、注意する必要がある点がいくつかあります:

1. 多くのコード ファイル、特に多くのインクルード ファイル (include または require) を含むファイルの場合。中間コードの解析と生成にはさらに時間がかかります。
2. PHP コードファイルに変更がなくても、実行処理は厳密に処理に従って実行されます。つまり、アプリケーション プログラムが変更されるかどうかに関係なく、アプリケーション プログラムを呼び出すたびに再コンパイルしてオペコードを生成する必要があります。 (実際、これがコンパイルキャッシュが存在する理由です)
3. このプロセスはメイン コード ファイル内で発生するだけでなく、すべての include および require に対しても実行されます。 (これは引き続き最適化される可能性があります)

どの領域を最適化できますか?

1. このモジュールを毎回ロードしないように mod_php fast-cgi を作成します。このモジュールも毎回 PHP 解釈環境を初期化する必要があります。
2. 毎回コンパイルすることを避けるために、php ファイルのオペコード コードをキャッシュします。
APC を使用してポイント 2 を達成できます。コンパイル キャッシュは PHP 実行中の解析プロセスを削除するため、大量の PHP コードを含むアプリケーションに非常に効果的です。通常の状況では、2 ～ 3 倍以上の速度を上げることができます。多数のインクルード ファイルを含むプロジェクトの場合、コンパイル キャッシュの利点がよりよく発揮されます。
注: include はコンパイル キャッシュにキャッシュされません。たとえば、main.php と tobeInclude.php という 2 つのファイルがあり、Main.php には include tobeInclude.php というステートメントがあります。中間コードの接尾辞は .op であると仮定します (これは当てはまりません)。次に、キャッシュ main.php=>main.op、tobeInclude.php=>tobeInclude.op を追加した後、ただし、PHP が main.php を実行するときは、依然として main.op 内の include コマンドを解析し、tobeInclude.op のコンテンツを呼び出す必要があります。具体的なプロセスは以下の通りです。
…=>main.op を実行=>tobeInclude.op=>を実行…
単に main.op を実行するのではなく
そのため、「インクルードファイルが多すぎるとプログラムのパフォーマンスが低下する」と言われています。

APC 固有の構成。
Alternative PHP Cache (APC) は、無料で公開されている、PHP 用に最適化されたコード キャッシュです。これは、PHP 中間コードをキャッシュおよび最適化するための、無料でオープンかつ堅牢なフレームワークを提供するために使用されます。
APC公式サイトは http://pecl.php.net/package/apc

1.インストール
PHP 拡張機能としてインストールします
ぴぴせ
./configure --enable-apc --enable-apc-mmap
作る
インストールする
.so を生成し、PHP がモジュールを参照するディレクトリに .so をコピーし、権限を 755 に変更します
2. 設定
apc.enabled ブール値
apc.optimization 最適化
オプションはスクリプトで変更できます
APC PHP.ini 設定オプションの詳細な説明
[APC]
; PHP 中間コードをキャッシュおよび最適化するための代替 PHP キャッシュ
apc.cache_by_default = オン
;シス
; すべてのファイルに対してデフォルトでバッファリングを有効にするかどうか。
; Off に設定し、プラス記号で始まる apc.filters ディレクティブと一緒に使用すると、ファイルはフィルターに一致する場合にのみキャッシュされます。
apc.enable_cli = オフ
;シス
; CLI ビルドで APC 機能を有効にするかどうかは、テストとデバッグの目的でのみこのディレクティブをオンにします。
apc.enabled = オン
; APC を有効にするかどうか。APC が静的に PHP にコンパイルされており、それを無効にしたい場合は、これが唯一の方法です。
apc.file_update_protection = 2
;シス
; 実行中のサーバー上のファイルを変更する場合は、アトミック操作を実行する必要があります。
; つまり、最初に一時ファイルに書き込み、次にファイルの名前を最終的な名前に変更 (mv) します。
; テキスト エディターや cp や tar などのプログラムはこのように動作しないため、不完全なファイルがバッファリングされる可能性があります。
; デフォルト値 2 は、ファイルにアクセスするときに、変更時間がアクセス時間から 2 秒未満であることが判明した場合、バッファリングは実行されないことを意味します。
; 運が悪い訪問者は破損したコンテンツを受け取る可能性がありますが、その悪影響はキャッシュによって増幅されません。
; すべての更新操作がアトミックであることを確認できる場合は、0 を指定してこの機能をオフにすることができます。
; IO 操作が多いためにシステムの更新が遅い場合は、この値を増やす必要がある場合があります。
apc.filters =
;シス
; POSIX 拡張正規表現のカンマ区切りのリスト。
; ソース ファイル名がいずれかのパターンに一致する場合、ファイルはキャッシュされません。
; マッチングに使用されるファイル名は、絶対パスではなく、include/require に渡されるファイル名であることに注意してください。
; 正規表現の最初の文字が「+」の場合、その正規表現に一致するファイルがキャッシュされることを意味します。 ; 最初の文字が「-」の場合、一致するものはキャッシュされません。 「-」はデフォルト値であり省略可能です。
apc.ttl = 0
;シス
; キャッシュ エントリがバッファ内に存在できる秒数。 0 はタイムアウトしないことを意味します。推奨値は7200～36000です。
; 0 に設定すると、バッファが古いキャッシュ エントリでいっぱいになり、新しいエントリがキャッシュされなくなる可能性があります。
apc.user_ttl = 0
;シス
; apc.ttl と似ていますが、各ユーザーの推奨値は 7200 ～ 36000 です。
; 0 に設定すると、バッファが古いキャッシュ エントリでいっぱいになり、新しいエントリがキャッシュされなくなる可能性があります。
apc.gc_ttl = 3600
;シス
; キャッシュ エントリがガベージ コレクション テーブルに存在できる秒数。
; この値は、キャッシュされたソース ファイルの実行中にサーバー プロセスがクラッシュした場合でも安全対策を提供します。 ; ソース ファイルが変更されている場合、古いバージョンに割り当てられたメモリは、この TTL 値に達するまで再利用されません。
; この機能を無効にするには、0 に設定します。
apc.include_once_override = オフ
;シス
; 予期しない結果が生じる可能性があるため、オフのままにしてください。
apc.max_file_size = 1M
;シス
; このサイズを超えるファイルがキャッシュされないようにします。
apc.mmap_file_mask =
;シス
; MMAP サポートが --enable-mmap (デフォルトで有効) を使用して APC 用にコンパイルされている場合、
; ここでの値は、mmap モジュールに渡される mktemp スタイルのファイル マスクです (推奨値は「/tmp/apc.XXXXXX」です)。
; このマスクは、メモリ マップ領域をファイル バックアップするか共有メモリ バックアップするかを決定するために使用されます。
; 直接ファイルバックアップメモリ​​マッピングの場合は、「/tmp/apc.XXXXXX」（正確に 6 つの X）に設定します。
; POSIX スタイルの shm_open/mmap を使用するには、「/apc.shm.XXXXXX」に設定する必要があります。
; 「/dev/zero」に設定して、匿名でマップされたメモリにカーネルの「/dev/zero」インターフェイスを使用することもできます。
; このディレクティブを定義しないと、匿名マッピングの使用が強制されます。
apc.num_files_hint = 1000
;シス
; Web サーバーに含めたりリクエストしたりできるさまざまなソース ファイルのおおよその数 (推奨値は 1024 ～ 4096)。
; よくわからない場合は、0 に設定してください。この設定は主に、数千のソース ファイルがあるサイトに役立ちます。
apc.最適化 = 0
; 最適化レベル (推奨値は 0)。
; 正の整数値はオプティマイザーを有効にし、値が大きいほどより積極的な最適化を使用します。
; 値を大きくすると、速度の改善が非常に限定される可能性がありますが、現在は実験段階です。
apc.report_autofilter = オフ
;シス
; 早期/遅延バインディングの理由により自動的にキャッシュされないすべてのスクリプトを記録するかどうか。
apc.shm_segments = 1
;シス
; コンパイラ バッファに割り当てられる共有メモリ ブロックの数 (推奨値は 1)。
; APC が共有メモリを使い果たし、apc.shm_size ディレクティブがシステムで許容される最大値に設定されている場合、
; この値を増やしてみてください。
apc.shm_size = 30
;シス
; 各共有メモリ ブロックのサイズ (MB 単位、推奨値は 128 ～ 256)。
; 一部のシステム (ほとんどの BSD バリアントを含む) のデフォルトの共有メモリ ブロック サイズは非常に小さいです。
apc.slam_defense = 0
;SYS (このコマンドの使用には反対です。apc.write_lock コマンドを使用することをお勧めします)
; 非常に負荷の高いサーバーでは、サービスの開始時でもファイルの変更時でも、
; 複数のプロセスが同時にファイルをキャッシュしようとするため、競合状態が発生する可能性があります。
; このディレクティブは、キャッシュされていないファイルを処理するときにプロセスがキャッシュ手順をスキップする割合を設定するために使用されます。
; たとえば、これを 75 に設定すると、キャッシュされていないファイルが見つかった場合に 75% の確率でキャッシュされないため、衝突の可能性が低くなります。
; この機能を無効にするには、0 に設定することをお勧めします。
apc.stat = オン
;シス
; スクリプトの更新チェックを有効にするかどうか。
; このディレクティブの値を変更する場合は十分に注意してください。
; デフォルト値 On は、APC がリクエストされるたびにスクリプトが更新されたかどうかを確認することを意味します。 ; 更新された場合は、コンパイルされたコンテンツを自動的に再コンパイルしてキャッシュします。ただし、これを行うとパフォーマンスに悪影響が生じます。
; Off に設定すると、チェックは実行されないため、パフォーマンスが大幅に向上します。
; ただし、更新されたコンテンツを有効にするには、Web サーバーを再起動する必要があります。
; このディレクティブは include/require ファイルにも有効です。ただし、注意してください
; 相対パスを使用する場合、APC はすべての include/require でファイルの場所を確認する必要があります。
; 絶対パスを使用するとチェックがスキップされる可能性があるため、include/require 操作には絶対パスを使用することをお勧めします。
apc.user_entries_hint = 100
;シス
; num_files_hint ディレクティブに似ていますが、ユーザーごとに異なります。
; よくわからない場合は 0 に設定してください。
apc.write_lock = オン
;シス
; 書き込みロックを有効にするかどうか。
; 非常に負荷の高いサーバーでは、サービスの開始時でもファイルの変更時でも、
; 複数のプロセスが同時にファイルをキャッシュしようとするため、競合状態が発生する可能性があります。
; 競合状態を回避するには、このディレクティブを有効にします。
apc.rfc1867 = オフ
;シス
; このディレクティブをオンにすると、APC は、ファイル フィールドの直前に APC_UPLOAD_PROGRESS フィールドを含むアップロード ファイルごとに、upload_ のユーザー キャッシュ エントリ (つまり、APC_UPLOAD_PROGRESS フィールドの値) を自動的に作成します。
3.php関数
apc_cache_info - APC のデータ ストアからキャッシュされた情報 (およびメタデータ) を取得します
apc_clear_cache - APC キャッシュをクリアします
apc_define_constants - 後で取得および一括定義するための定数のセットを定義します
apc_delete - 保存された変数をキャッシュから削除します
apc_fetch - 保存された変数をキャッシュからフェッチします
apc_load_constants - キャッシュから一連の定数をロードします
apc_sma_info - APC の共有メモリ割り当て情報を取得します
apc_store —データストアに変数をキャッシュします

4. 注意:

Apc と Apache プロセスはメモリを共有するため、Apache プロセスが実行される場合にのみ値を apc に保存できます。通常の PHP プロセスは APC 共有メモリにアクセスできません。

第 3 章 PHP パフォーマンスを向上させるコーディングのヒント

0. 文字列を含めるには二重引用符の代わりに一重引用符を使用すると高速になります。 PHP は二重引用符で囲まれた文字列内の変数を検索しますが、一重引用符は検索しません。 注: これを実行できるのは echo だけです。これは複数の文字列をパラメータとして受け取ることができる「関数」です (注釈: PHP マニュアル echo は実際の関数ではなく言語構造であるため、関数は二重引用符で囲まれています)。
1. クラスメソッドを静的に定義できる場合は、クラスメソッドを静的に定義してみると、速度が 4 倍近く向上します。
2. $row['id'] の速度は $row[id] の 7 倍です。
3. Echo は print より高速で、echo $str1、$str2 などの文字列連結の代わりに echo の複数のパラメータ (注釈: ピリオドの代わりにカンマを使用することを指します) を使用します。
4. for ループを実行する前に最大ループ数を決定します。ループごとに最大値を計算するのではなく、代わりに foreach を使用することをお勧めします。
5. 未使用の変数、特に大きな配列の登録を解除して、メモリを解放します。
6. __get、__set、__autoload の使用は避けてください。
7. require_once() は高価です。
8. ファイルをインクルードする場合は、絶対パスを使用するようにしてください。これにより、include_path 内のファイルを検索する PHP の速度が低下し、オペレーティング システムのパスの解析に必要な時間が短縮されるためです。
9. スクリプトの実行開始時刻 (注釈: サーバーがクライアント要求を受信する時刻) を知りたい場合は、time() よりも $_SERVER['REQUEST_TIME'] を使用する方が適切です。
10. 関数は正規表現を置き換えて、同じ関数を完成させます。
11. str_replace 関数は preg_replace 関数より高速ですが、strtr 関数は str_replace 関数より 4 倍効率的です。
12. 文字列置換関数が配列または文字をパラメータとして受け入れることができ、パラメータの長さが長すぎない場合は、単に 1 行を記述するのではなく、渡される各パラメータが文字になるように追加の置換コードを記述することを検討できます。クエリおよび置換のパラメータとして配列を受け入れるコード。
13. 複数の if、else if ステートメントを使用するよりも、選択的分岐ステートメント (翻訳アノテーション: switch case) を使用する方が適切です。
14. @ を使用してエラー メッセージをブロックするのは非常に非効率的です。
15. Apache の mod_deflate モジュールを開いて、Web ページの閲覧速度を向上させます。
16. データベース接続は、使用が終了したら閉じる必要があり、長い接続を使用しないでください。
17. エラー メッセージは高価です。
18. メソッド内でローカル変数をインクリメントするのが最も高速です。関数内でローカル変数を呼び出すのとほぼ同じ速度です。
19. グローバル変数のインクリメントは、ローカル変数のインクリメントより 2 倍遅くなります。
20. オブジェクト プロパティ (例: $this->prop++) のインクリメントは、ローカル変数のインクリメントより 3 倍遅くなります。
21. 未定義のローカル変数をインクリメントするのは、事前定義されたローカル変数をインクリメントするよりも 9 ～ 10 倍遅くなります。
22. 関数内で呼び出さずにローカル変数を定義するだけでも、(ローカル変数をインクリメントするのと同じ程度に) 速度が低下します。 PHP はおそらく、グローバル変数が存在するかどうかを確認します。
23. 10 個のメソッドを (メソッドのテスト前とテスト後の両方で) 追加しましたが、パフォーマンスに変化はなかったので、メソッド呼び出しはクラスで定義されたメソッドの数とは無関係であるように見えます。
24. 派生クラスのメソッドは、基本クラスで定義された同じメソッドよりも高速に実行されます。
25. 1 つのパラメーターを指定して空の関数を呼び出すには、7 ～ 8 回のローカル変数のインクリメント操作を実行するのと同じ時間がかかります。同様のメソッド呼び出しには、15 近くのローカル変数のインクリメント操作が必要です。
26. Apache は、PHP スクリプトを解析するのに、静的な HTML ページを解析するよりも 2 ～ 10 倍遅くなります。使用する静的な HTML ページを増やし、スクリプトを減らすようにしてください。
27. スクリプトをキャッシュできない限り、呼び出されるたびに再コンパイルされます。 PHP キャッシュ メカニズムを導入すると、通常、コンパイルのオーバーヘッドが排除され、パフォーマンスが 25% ～ 100% 向上します。
28. できるだけキャッシュするようにしてください。memcached を使用できます。 Memcached は、動的 Web アプリケーションを高速化し、データベースの負荷を軽減するために使用できる高性能メモリ オブジェクト キャッシュ システムです。 OP コードのキャッシュは、リクエストごとにスクリプトを再コンパイルする必要がないように便利です。
29. 文字列を操作し、その長さが特定の要件を満たしているかどうかを確認する必要がある場合は、当然 strlen() 関数を使用します。この関数は計算を行わず、zval 構造体 (PHP 変数の格納に使用される C の組み込みデータ構造体) に格納されている既知の長さの文字列を返すだけなので、非常に高速に実行されます。ただし、strlen() は関数であるため、関数呼び出しは小文字などの多くの手順を経るため、多少遅くなります (注釈: 小文字の関数名を指します。PHP は関数名の大文字と小文字を区別しません)。 )、ハッシュ検索、呼び出された関数と一緒に実行されます。場合によっては、 isset() トリックを使用してコードの実行を高速化できます。
(下記例)
if (strlen($foo) (以下のヒントと比較してください)
if (!isset($foo{5})) { echo "Foo は短すぎます"$$ }
isset() の呼び出しは、strlen() よりも高速です。これは、後者とは異なり、言語構造としての isset() の実行に関数の検索や小文字が必要ないためです。つまり、文字列の長さをチェックするトップレベルのコードでは、実際には多くのオーバーヘッドが費やされません。
34. 変数 $i のインクリメントまたはデクリメントを実行する場合、$i++ は ++$i より遅くなります。この違いは PHP に固有のものであり、他の言語には当てはまりません。そのため、C または Java コードを変更して、すぐに高速になることを期待しないでください。実際には機能しません。 ++$i は 3 つの命令 (オペコード) しか必要としないため高速ですが、$i++ は 4 つの命令を必要とします。ポストインクリメントでは、実際には、後でインクリメントされる一時変数が作成されます。プレフィックスの増分は、元の値に直接増加します。これは、Zend の PHP オプティマイザーによって行われるような、最適化の一種です。すべてのコマンド オプティマイザーが同じ最適化を行うわけではなく、コマンド オプティマイザーがインストールされていないインターネット サービス プロバイダー (ISP) やサーバーが多数存在するため、この最適化を念頭に置くことをお勧めします。
35. すべてがオブジェクト指向 (OOP) である必要はありません。オブジェクト指向は多くの場合非常に高価で、各メソッドとオブジェクトの呼び出しは大量のメモリを消費します。
36. すべてのデータ構造を実装するためにクラスを使用する必要はありません。配列も便利です。
37. メソッドを細分化しすぎないでください。実際にどのコードを再利用するかを慎重に考えてください。
38. 必要に応じていつでもコードをメソッドに分割できます。
39. できるだけ多くの PHP 組み込み関数を使用するようにしてください。
40. コード内に時間のかかる関数が多数ある場合は、それらを C 拡張機能として実装することを検討できます。
41. コードのプロファイリングを行います。チェッカーは、コードのどの部分にどれくらいの時間がかかっているかを示します。 Xdebug デバッガーには、コードの全体的な整合性を評価し、コード内のボトルネックを明らかにする検査ルーチンが含まれています。
42. mod_zip を Apache モジュールとして使用すると、データを瞬時に圧縮し、データ転送量を 80% 削減できます。
43. file、fopen、feof、fgets などの一連のメソッドの代わりに file_get_contents を使用できる場合は、より効率的である file_get_contents を使用するようにしてください。ただし、URL ファイルを開くときは、file_get_contents の PHP バージョンの問題に注意してください。
44. PHP のファイル操作効率は低くありませんが、ファイル操作は最小限に抑えます。 45. Select SQL ステートメントを最適化し、実行する挿入操作と更新操作をできるだけ少なくします。 46. 可能な限り PHP 内部関数を使用します (ただし、PHP に存在しない関数を見つけるために、カスタム関数を作成できたはずの時間を無駄にしました。これは経験の問題です!); 47. ループ内で変数、特に大きな変数: オブジェクトを使用しないでください (これは PHP だけの問題ではないようですよね?)。 48. 多次元配列のループ内で代入を入れ子にしないようにしてください。 49. PHP の内部文字列操作関数を使用できる場合は、正規表現を使用しないでください。 50. foreach の方が効率的です。while や for ループの代わりに foreach を使用してみてください。 51. 文字列を引用するには二重引用符の代わりに一重引用符を使用します。 52. 「i=i+1 の代わりに i+=1 を使用します。これは C/C++ の習慣に従っており、より効率的です。」; 53. グローバル変数は使用後に unset() する必要があります




http://www.bkjia.com/PHPjc/1133122.html

www.bkjia.com

本当

http://www.bkjia.com/PHPjc/1133122.html

技術記事 PHP パフォーマンス最適化事典 (php.ini)、パフォーマンス最適化 php.ini 第 1 章 システム コールが多すぎる場合の最適化 今回の最適化は、システム コール コールが多すぎる問題を対象としているため、apac を追跡するために strace を使用します...