PHP5.1 5000 個の数値を使用したクイック ソートの平均応答時間は 2587ms です。
PHP5.2 5000 個の数値によるクイック ソートの平均応答時間は 2625 ミリ秒です。
PHP5.3 5000 個の数値によるクイック ソートの平均応答時間は 2509 ミリ秒です。
PHP5.4 5000 個の数値によるクイック ソートの平均応答時間は 2339 ミリ秒
PHP7.0 5000数値クイックソート 平均応答時間 685ms
PHP5.1 WordPress 平均応答時間 505ms
PHP5.2 WordPress 平均応答時間521ms
PHP5.3 WordPress 平均応答時間 498ms
PHP5.4 WordPress 平均応答時間 470ms
PHP7.0 WordPress 平均応答時間 158ms
PHP5.4 500 クイック ソート TPS 552
PHP7.0 500 番号クイック ソート TPS 3165
Flyme コミュニティ APP ホーム ページ PHP5.4 TPS 1535
Flyme コミュニティ APP ホームページ PHP7.0 TPS 1975
Flyme コミュニティ APP セクション リスト ページ PHP5.4 TPS 2237
Flyme コミュニティ APP セクション リスト ページ PHP7.0 TPS 2387
1. JIT
2. Zval の変更点
3. 内部型 zend_string
4. PHP 配列 (HashTable および Zend Array) の変更点
5. 関数呼び出しメカニズム (Function呼び出し規約)
6. マクロ定義とインライン関数 (inline) により、コンパイラに作業の一部を事前に完了させます
Redis プロキシの目的は、Redis の高可用性と分散キャッシュです
合格 パフォーマンス テストは比較的直接接続ですプロキシの使用によるパフォーマンスの損失は約 10 ~ 15% です (ビジネスによって比較的大きな差が生じる可能性があります)
それでは、プロキシを最適化する余地はあるのでしょうか?
PHP7 Redis の長い接続のパフォーマンスは、短い接続のパフォーマンスよりも約 10% 高い (ビジネスによって大きく異なります)
データベース接続プールは、データベース接続の割り当て、管理、解放を担当します。これにより、アプリケーションは新しいデータベース接続を確立する代わりに、既存のデータベース接続を再利用できるようになります。
Atlas は、360 によって開発および保守されているデータベース ミドルウェアです。アプリケーションと MySQL の間に位置し、MySQL のクライアント/サーバー プロトコルを実装し、サーバーとしてアプリケーションと通信し、クライアントとして MySQL と通信します。 DB の詳細をアプリケーションから保護し、MySQL の負担を軽減します。
Atlas は、読み取り、読み取りと書き込みの分離、自動テーブル シャーディング、セキュリティ処理、スムーズな再起動、接続プールなどに影響を与えることなく、メイン データベースのダウンタイムをサポートします。
データベース接続プールの使用後、TPS パフォーマンス レバレッジは 80 倍に増加します。 %
効果を見てみましょう
Opcache の高速化方法
opcache を追加した後の結果を見てください (リクエストの平均、応答時間は
PGO は、コンパイル最適化テクノロジです。 GCC などのコンパイラで使用すると、コンパイラのコンパイル効率を向上させることができます。
PGO はコンパイル効率を向上させることができますが、あまり広く使用されていません。
理由は非常に単純です:
1. 複雑な二重コンパイル モデルと限られた使用シナリオにより、PGO は役に立たないように見えます
2. opcache のような製品の出現後、PGO によってもたらされるパフォーマンスの向上はあまり明らかではありません。
<source lang="xml" collapse="false" first-line="1"> #php-fpm.conf listen = /dev/shm/php-fcgi.sock #php-fpm2.conf listen = /dev/shm/php-fcgi2.sock #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm.conf #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm2.conf #代理 upstream backend{ server unix:/dev/shm/php-fcgi.sock; server unix:/dev/shm/php-fcgi2.sock; } </source>
HugePage (2%-3% 増加)
テーブル ルックアップ プロセスを高速化するために、CPU には組み込みのTLB (Translation Lookaside Buffer)。仮想ページが小さいほど、テーブル内のエントリの数は多くなります。
そして、TLB サイズには制限があります。エントリが多いほど、TLB のキャッシュ ミスが増加します。したがって、大きなメモリ ページを有効にできれば、この TLB キャッシュ ミスを間接的に減らすことができます。
<source lang="xml" collapse="false" first-line="1"> opcache.huge_code_pages=1 sudo sysctl vm.nr_hugepages=128 </source>
フェーズ パフォーマンス パラメーターの最適化
<source lang="xml" collapse="false" first-line="1"> opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.save_comments=0 opcache.fast_shutdown=1 opcache.huge_code_pages=1 opcache.file_cache=/dev/shm/opcache/ </source>
<source lang="xml" collapse="false" first-line="1"> listen = /dev/shm/php-fcgi.sock pm = static pm.max_children = 320 pm.max_requests = 10240 </source>
以上がPHP7のパフォーマンスの変化が1分でわかる(パフォーマンスが4倍に向上)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。