ホームページ バックエンド開発 PHPチュートリアル 使用Huagepage和PGO来提升PHP7的执行性能_php技巧

使用Huagepage和PGO来提升PHP7的执行性能_php技巧

May 16, 2016 pm 08:04 PM
php7 パフォーマンス

Hugepage
PHP7刚刚发布了RC4, 包含一些bug修复和一个我们最新的性能提升成果, 那就是”HugePageFy PHP TEXT segment”, 通过启用这个特性,PHP7会把自身的TEXT段(执行体)”挪“到Huagepage上,之前的测试,我们能稳定的在Wordpress上看到2%~3%的QPS提升。

关于Hugepage是啥,简单的说下就是默认的内存是以4KB分页的,而虚拟地址和内存地址是需要转换的, 而这个转换是要查表的,CPU为了加速这个查表过程都会内建TLB(Translation Lookaside Buffer), 显而易见如果虚拟页越小,表里的条目数也就越多,而TLB大小是有限的,条目数越多TLB的Cache Miss也就会越高, 所以如果我们能启用大内存页就能间接降低这个TLB Cache Miss,至于详细的介绍,Google一搜一大堆我就不赘述了,这里主要说明下如何启用这个新特性, 从而带来明显的性能提升。

新的Kernel启用Hugepage已经变得非常容易了,以我的开发虚拟机为例(Ubuntu Server 14.04,Kernel 3.13.0-45), 如果我们查看内存信息:

$ cat /proc/meminfo | grep Huge
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
AnonHugePages:  444416 kB
HugePages_Total:    0
HugePages_Free:    0
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:    2048 kB
ログイン後にコピー

可见一个Hugepage的size是2MB, 而当前并没有启用HugePages. 现在让我们先编译PHP RC4, 记得一定不要加: –disable-huge-code-pages (这个新特性是默认启用的, 你加了这个就关了)

然后配置opcache, 从PHP5.5开始Opcache已经是默认启用编译的,但是是编译动态库的, 所以我们还是要在php.ini中配置加载下。

zend_extension=opcache.so
ログイン後にコピー

这个新特性是做在Opcache里的,所以也要通过Opcache启用这个特性(通过设置opcache.huge_code_pages=1), 具体的配置:

opcache.huge_code_pages=1
ログイン後にコピー

现在让我们配置OS, 分配一些Hugepages:

$ sudo sysctl vm.nr_hugepages=128
vm.nr_hugepages = 128
ログイン後にコピー

现在让我们再次检查内存信息:

$ cat /proc/meminfo | grep Huge
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
AnonHugePages:  444416 kB
HugePages_Total:   128
HugePages_Free:   128
HugePages_Rsvd:    0
HugePages_Surp:    0
Hugepagesize:    2048 kB
ログイン後にコピー

可以看到我们分配的128个Hugepages已经就绪了, 然后我们来启动php-fpm:

$ /home/huixinchen/local/php7/sbin/php-fpm
ログイン後にコピー
[01-Oct-2015 09:33:27] NOTICE: [pool www] 'user' directive is ignored when FPM is not running as root
[01-Oct-2015 09:33:27] NOTICE: [pool www] 'group' directive is ignored when FPM is not running as root
ログイン後にコピー

现在, 再次检查内存信息:

$ cat /proc/meminfo | grep Huge
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
AnonHugePages:  411648 kB
HugePages_Total:   128
HugePages_Free:   113
HugePages_Rsvd:    27
HugePages_Surp:    0
Hugepagesize:    2048 kB
ログイン後にコピー

说到这里,如果Hugepages可用, 其实Opcache也会用Hugepages来存储opcodes缓存, 所以为了验证opcache.huge_code_pages确实生效, 我们不妨关闭opcache.huge_code_pages, 然后再启动一次后看内存信息:

$ cat /proc/meminfo | grep Huge
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
ログイン後にコピー
AnonHugePages:  436224 kB
HugePages_Total:   128
HugePages_Free:   117
HugePages_Rsvd:    27
HugePages_Surp:    0
Hugepagesize:    2048 kB
ログイン後にコピー

可见开启了huge_code_pages以后, fpm启动后多用了4个pages, 现在我们检查下php-fpm的text大小:

$ size /home/huixinchen/local/php7/sbin/php-fpm
ログイン後にコピー
  text    data     bss     dec     hex   filename
10114565   695200   131528   10941293   a6f36d   /home/huixinchen/local/php7/sbin/php-fpm
ログイン後にコピー

可见text段有10114565个字节大小, 总共需要占用4.8个左右的2M的pages, 考虑到对齐以后(尾部不足2M Page部分不挪动), 申请4个pages, 正好和我们看到的相符。

说明配置成功! Enjoy :)

但是有言在先, 启用此特性以后, 会造成一个问题就是你如果尝试通过Perf report/anno 去profiling的时候, 会发现符号丢失(valgrind, gdb不受影响), 这个主要原因是Perf的设计采用监听了mmap,然后记录地址范围, 做IP到符号的转换, 但是目前HugeTLB只支持MAP_ANON, 所以导致Perf认为这部分地址没有符号信息,希望以后版本的Kernel可以修复这个限制吧..

GCC PGO
PGO正如名字所说(Profile Guided Optimization 有兴趣的可以Google), 他需要用一些用例来获得反馈, 也就是说这个优化是需要和一个特定的场景绑定的.

你对一个场景的优化, 也许在另外一个场景就事与愿违了. 它不是一个通用的优化. 所以我们不能简单的就包含这些优化, 也无法直接发布PGO编译后的PHP7.

当然, 我们正在尝试从PGO找出一些共性的优化, 然后手工Apply到PHP7上去, 但这个很明显不能做到针对一个场景的特别优化所能达到的效果, 所以我决定写这篇文章简单介绍下怎么使用PGO来编译PHP7, 让你编译的PHP7能特别的让你自己的独立的应用变得更快.

首先, 要决定的就是拿什么场景去Feedback GCC, 我们一般都会选择: 在你要优化的场景中: 访问量最大的, 耗时最多的, 资源消耗最重的一个页面.

拿Wordpress为例, 我们选择Wordpress的首页(因为首页往往是访问量最大的).

我们以我的机器为例:

Intel(R) Xeon(R) CPU X5687 @ 3.60GHz X 16(超线程),
48G Memory
php-fpm 采用固定32个worker, opcache采用默认的配置(一定要记得加载opcache)

以wordpress 4.1为优化场景..

首先我们来测试下目前WP在PHP7的性能(ab -n 10000 -c 100):

$ ab -n 10000 -c 100 http://inf-dev-maybach.weibo.com:8000/wordpress/
ログイン後にコピー
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking inf-dev-maybach.weibo.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
 
Server Software:    nginx/1.7.12
Server Hostname:    inf-dev-maybach.weibo.com
Server Port:      8000
 
Document Path:     /wordpress/
Document Length:    9048 bytes
 
Concurrency Level:   100
Time taken for tests:  8.957 seconds
Complete requests:   10000
Failed requests:    0
Write errors:      0
Total transferred:   92860000 bytes
HTML transferred:    90480000 bytes
Requests per second:  1116.48 [#/sec] (mean)
Time per request:    89.567 [ms] (mean)
Time per request:    0.896 [ms] (mean, across all concurrent requests)
Transfer rate:     10124.65 [Kbytes/sec] received
ログイン後にコピー

可见Wordpress 4.1 目前在这个机器上, 首页的QPS可以到1116.48. 也就是每秒钟可以处理这么多个对首页的请求,

现在, 让我们开始教GCC, 让他编译出跑Wordpress4.1更快的PHP7来, 首先要求GCC 4.0以上的版本, 不过我建议大家使用GCC-4.8以上的版本(现在都GCC-5.1了).

第一步, 自然是下载PHP7的源代码了, 然后做./configure. 这些都没什么区别

接下来就是有区别的地方了, 我们要首先第一遍编译PHP7, 让它生成会产生profile数据的可执行文件:

$ make prof-gen
ログイン後にコピー

注意, 我们用到了prof-gen参数(这个是PHP7的Makefile特有的, 不要尝试在其他项目上也这么搞哈 :) )

然后, 让我们开始训练GCC:

$ sapi/cgi/php-cgi -T 100 /home/huixinchen/local/www/htdocs/wordpress/index.php >/dev/null
ログイン後にコピー

也就是让php-cgi跑100遍wordpress的首页, 从而生成一些在这个过程中的profile信息.

然后, 我们开始第二次编译PHP7.

$ make prof-clean
$ make prof-use && make install
ログイン後にコピー

好的, 就这么简单, PGO编译完成了, 现在我们看看PGO编译以后的PHP7的性能:

$ ab -n10000 -c 100 http://inf-dev-maybach.weibo.com:8000/wordpress/
ログイン後にコピー
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking inf-dev-maybach.weibo.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
 
Server Software:    nginx/1.7.12
Server Hostname:    inf-dev-maybach.weibo.com
Server Port:      8000
 
Document Path:     /wordpress/
Document Length:    9048 bytes
 
Concurrency Level:   100
Time taken for tests:  8.391 seconds
Complete requests:   10000
Failed requests:    0
Write errors:      0
Total transferred:   92860000 bytes
HTML transferred:    90480000 bytes
Requests per second:  1191.78 [#/sec] (mean)
Time per request:    83.908 [ms] (mean)
Time per request:    0.839 [ms] (mean, across all concurrent requests)
Transfer rate:     10807.45 [Kbytes/sec] received
ログイン後にコピー

现在每秒钟可以处理1191.78个QPS了, 提升是~7%. 还不赖哈(咦, 你不是说10%么? 怎么成7%了? 呵呵, 正如我之前说过, 我们尝试分析PGO都做了些什么优化, 然后把一些通用的优化手工Apply到PHP7中. 所以也就是说, 那~3%的比较通用的优化已经包含到了PHP7里面了, 当然这个工作还在继续).

于是就这么简单, 大家可以用自己的产品的经典场景来训练GCC, 简单几步, 获得提升, 何乐而不为呢

このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

Embedding サービスのローカル実行パフォーマンスは OpenAI Text-Embedding-Ada-002 を上回っており、とても便利です。 Embedding サービスのローカル実行パフォーマンスは OpenAI Text-Embedding-Ada-002 を上回っており、とても便利です。 Apr 15, 2024 am 09:01 AM

Ollama は、Llama2、Mistral、Gemma などのオープンソース モデルをローカルで簡単に実行できるようにする非常に実用的なツールです。この記事では、Ollamaを使ってテキストをベクトル化する方法を紹介します。 Ollama をローカルにインストールしていない場合は、この記事を読んでください。この記事では、nomic-embed-text[2] モデルを使用します。これは、短いコンテキストおよび長いコンテキストのタスクにおいて OpenAI text-embedding-ada-002 および text-embedding-3-small よりも優れたパフォーマンスを発揮するテキスト エンコーダーです。 o が正常にインストールされたら、nomic-embed-text サービスを開始します。

さまざまな Java フレームワークのパフォーマンスの比較 さまざまな Java フレームワークのパフォーマンスの比較 Jun 05, 2024 pm 07:14 PM

さまざまな Java フレームワークのパフォーマンス比較: REST API リクエスト処理: Vert.x が最高で、リクエスト レートは SpringBoot の 2 倍、Dropwizard の 3 倍です。データベース クエリ: SpringBoot の HibernateORM は Vert.x や Dropwizard の ORM よりも優れています。キャッシュ操作: Vert.x の Hazelcast クライアントは、SpringBoot や Dropwizard のキャッシュ メカニズムよりも優れています。適切なフレームワーク: アプリケーションの要件に応じて選択します。Vert.x は高パフォーマンスの Web サービスに適しており、SpringBoot はデータ集約型のアプリケーションに適しており、Dropwizard はマイクロサービス アーキテクチャに適しています。

PHP 配列キー値の反転: さまざまな方法のパフォーマンス比較分析 PHP 配列キー値の反転: さまざまな方法のパフォーマンス比較分析 May 03, 2024 pm 09:03 PM

PHP の配列キー値の反転メソッドのパフォーマンスを比較すると、array_flip() 関数は、大規模な配列 (100 万要素以上) では for ループよりもパフォーマンスが良く、所要時間が短いことがわかります。キー値を手動で反転する for ループ方式は、比較的長い時間がかかります。

C++ でマルチスレッド プログラムのパフォーマンスを最適化するにはどうすればよいですか? C++ でマルチスレッド プログラムのパフォーマンスを最適化するにはどうすればよいですか? Jun 05, 2024 pm 02:04 PM

C++ マルチスレッドのパフォーマンスを最適化するための効果的な手法には、リソースの競合を避けるためにスレッドの数を制限することが含まれます。競合を軽減するには、軽量のミューテックス ロックを使用します。ロックの範囲を最適化し、待ち時間を最小限に抑えます。ロックフリーのデータ構造を使用して同時実行性を向上させます。ビジー待機を回避し、イベントを通じてリソースの可用性をスレッドに通知します。

C++ 静的関数のパフォーマンスに関する考慮事項は何ですか? C++ 静的関数のパフォーマンスに関する考慮事項は何ですか? Apr 16, 2024 am 10:51 AM

静的関数のパフォーマンスに関する考慮事項は次のとおりです。 コード サイズ: 静的関数にはメンバー変数が含まれないため、通常は小さくなります。メモリ占有: 特定のオブジェクトに属さず、オブジェクト メモリを占有しません。呼び出しオーバーヘッド: 低くなり、オブジェクト ポインターまたは参照を介して呼び出す必要がありません。マルチスレッド セーフ: クラス インスタンスに依存しないため、通常はスレッド セーフです。

ベンチマークを使用して Java 関数のパフォーマンスを評価するにはどうすればよいですか? ベンチマークを使用して Java 関数のパフォーマンスを評価するにはどうすればよいですか? Apr 19, 2024 pm 10:18 PM

Java 関数のパフォーマンスをベンチマークする方法は、Java Microbenchmark Suite (JMH) を使用することです。具体的な手順は次のとおりです。 JMH 依存関係をプロジェクトに追加します。新しい Java クラスを作成し、ベンチマーク メソッドを表す @State アノテーションを付けます。クラス内にベンチマーク メソッドを記述し、 @Benchmark アノテーションを付けます。 JMH コマンド ライン ツールを使用してベンチマークを実行します。

PHP 配列をオブジェクトに変換すると、パフォーマンスにどのような影響がありますか? PHP 配列をオブジェクトに変換すると、パフォーマンスにどのような影響がありますか? Apr 30, 2024 am 08:39 AM

PHP では、配列からオブジェクトへの変換はパフォーマンスに影響を与え、主に配列のサイズ、複雑さ、オブジェクト クラスなどの要因によって影響を受けます。パフォーマンスを最適化するには、カスタム反復子の使用、不必要な変換の回避、配列のバッチ変換などの手法を検討してください。

PHP 関数のパフォーマンスはどの程度ですか? PHP 関数のパフォーマンスはどの程度ですか? Apr 18, 2024 pm 06:45 PM

さまざまな PHP 関数のパフォーマンスは、アプリケーションの効率にとって非常に重要です。パフォーマンスの良い関数には echo や print などがありますが、str_replace、array_merge、file_get_contents などの関数のパフォーマンスは低くなります。たとえば、str_replace 関数は文字列の置換に使用され、中程度のパフォーマンスを発揮しますが、sprintf 関数は文字列の書式設定に使用されます。パフォーマンス分析によると、1 つの例の実行にかかる時間はわずか 0.05 ミリ秒であり、関数が適切に実行されることが証明されています。したがって、関数を賢く使用すると、アプリケーションをより高速かつ効率的に実行できます。

See all articles