GoとPHPのパフォーマンス比較についての考え

考える

Go と PHP を合理的な構成 (メインストリーム フレームワーク) で使用して同じ機能を実装すると、パフォーマンスの差は桁違いになります。もちろん、ほとんどのビジネス シナリオを考慮すると、PHP の使用を強くお勧めします。結局のところ、配列ツールキットとフレームワーク ツールキットは実際には非常に重要です。役に立つ！フロントエンド アプリケーションの場合、特に同時実行性の高いシナリオでは、依然として慎重に選択する必要があると思います。もちろん、PHP の swoole フレームワークとワーカーマン フレームワークに切り替えると、質的な飛躍が得られます。ただし、現在の雇用状況から判断すると、はい、結局のところ、今は PHP の給与を上げる余地があります。

準備

腹圧テストツール

行く：

• バージョン: 1.19.4
• フレーム：なし
• MySQL 接続プールを使用するかどうか: はい、最大接続数は 100関連コード
• ロギング: はい、seelog を使用します

PHP：

• バージョン: 8.1.15
• フレームワーク: Yii2 2.0.47
• キャッシュ: opcache、jit 設定を有効にする
• FastFpm: ダイナミック モード、最大プロセス数: 64 (メモリはすでに 150MB ですが、Go はわずか 2MB、ここでの k8s は 1 コアと 2g で構成されています)
• ロギング: はい、Yii ロガーを使用します。

PHP opcache 構成は次のとおりです (コードは更新されず、キャッシュが強制されます)

[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=192
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000

# 组合使用, 若为 1 则在 revalidate_freq 时间内刷新代码
opcache.validate_timestamps=0
# opcache.revalidate_freq=60

; jit配置
opcache.jit=true
opcache.jit_buffer_size=64M 

pm = dynamic
pm.max_children = 64
pm.start_servers = 32
pm.min_spare_servers = 16
pm.max_spare_servers = 64

テストプログラム

• QPS 20、50、100、および 200 の条件下で、対応するプログラムをそれぞれストレス テストして、対応する時間と分位値を確認します。
• 記憶比較、諦める（比べられない）

試験結果

合計数: 1000

SWC	行く	PHP	述べる
20	QPS：798.01 AVG：25.062ミリ秒	QPS：99.98 AVG：200.030ミリ秒	PHP は主に、DB 自身の接続作成や言語自体よりも遅いです。
50	QPS: 1593.46 AVG：31.378 ミリ秒	QPS：129.75 AVG：385.357ミリ秒	接続が再利用され始めるため、Go QPS が向上します
100	QPS: 1387.81 AVG：72.056 ミリ秒	QPS：121.31 AVG：824.302ミリ秒	平均消費時間の増加はデータベースの負荷によるもので、PHP も FPM プロセスの破棄と作成によりインターフェイスの負荷を増大させ始めます (もちろん、常駐するように構成することもできます。現在 32)
200	QPS: 1355.24 AVG：147.575 ミリ秒	QPS：118.41 AVG：1689.022ミリ秒	GO ではデータベース接続の数がいっぱいで待機する必要があるため、平均応答時間が長くなります。一方、PHP では最大 FPM が 64 であるため、同時実行の上限が制限されます。

関連するスクリーンショットは次のとおりです (左側が Go、右側が PHP)

チップ

関連するコマンドとパラメータの説明

# 查询当前 php-fpm 进程数
ps -ef |grep "php-fpm"|grep "pool"|wc -l

# 查询内存占用
free -m

PHP オプキャッシュ

OpCache を有効にし、コマンド ライン モードで OpCache を有効にします。これは、 opcache.enable および opcache.enable_cli パラメータを 1 に設定することで実現できます。
サーバーのハードウェア構成に合わせてメモリ消費量を調整します。通常、 opcache.memory_consumption を 128MB以上に設定することをお勧めします。
文字列バッファのサイズを増やすには、opcache.interned_strings_buffer パラメータを 16MB 以上に設定します。
高速化できるスクリプト ファイルの最大数を増やすには、opcache.max_accelerated_files パラメータを 4000 以上に設定します。
タイムスタンプ検証をオフにするには、opcache.validate_timestamps パラメータを 0 に設定します。
opcache.revalidate_freq パラメータを 60 秒以上に設定して、キャッシュ内のファイルを再検証する時間間隔を設定します。
opcache.fast_shutdown パラメータを 1 に設定して、高速シャットダウンを有効にします。
opcache.enable_file_override パラメータを 1 に設定することで、スクリプトがキャッシュ ファイルをオーバーライドできるようにします。
ブラックリストへのキャッシュが禁止されているファイルをリストするには、opcache.blacklist_filename パラメーターを設定します。これにより、キャッシュすべきではないファイルがキャッシュに追加されることがなくなります。
エラー ログ ファイルのパスを設定するには、opcache.error_log パラメータを設定します。これは、潜在的な問題を迅速に特定して修正するのに役立ちます。

ab 共通パラメータの説明

-n：指定总请求数。例如，-n 1000表示发出1000个请求。

-c：指定并发请求数。例如，-c 10表示同时发出10个请求。

-t：指定测试持续时间，单位为秒。例如，-t 60表示测试持续60秒。

-k：启用HTTP KeepAlive功能，即在一次TCP连接中处理多个HTTP请求。默认情况下，ab在每个请求之间关闭连接。

-p：指定包含POST数据的文件。例如，-p postdata.txt表示从postdata.txt文件中读取POST数据。

-H：指定请求头。例如，-H "Accept-Encoding: gzip, deflate"表示在请求头中设置Accept-Encoding字段。

-A：指定HTTP认证信息。例如，-A "username:password"表示使用基本的HTTP认证。

-s：指定测试期间等待服务器响应的最大时间，单位为秒。例如，-s 10表示等待服务器响应的最大时间为10秒。

-v：输出详细的调试信息，包括请求和响应头。

-V：输出版本信息。

ab ツールによって返される結果の説明

		Benchmarking www.baidu.com (be patient).....done
		
		
		Server Software:        Apache   // web 服务软件名称
		Server Hostname:        www.baidu.com  // 请求域名
		Server Port:            80 // 请求端口
		
		Document Path:          /a // 请求路径（get 参数可以携带参数）
		Document Length:        199 bytes // 文档字节
		
		Concurrency Level:      20 // 并发数  -c 控制
		Time taken for tests:   1.054 seconds // 任务请求耗时
		Complete requests:      100 // 任务请求完成数量
		Failed requests:        0 // 任务失败请求数量
		Non-2xx responses:      100 // HTTP 码非 200 数量
		Total transferred:      34400 bytes // 相应字符数
		HTML transferred:       19900 bytes // 
		Requests per second:    94.86 [#/sec] (mean) // 平均每秒请求数
		Time per request:       210.841 [ms] (mean) //  批次平均耗时
		Time per request:       10.542 [ms] (mean, across all concurrent requests) // 单个请求的平均耗时 （基本等于 自身 * 并发数， 因为并发其实是 cpu 时间片轮询的）
		Transfer rate:          31.87 [Kbytes/sec] received // 每秒字节数
		
		Connection Times (ms)
		              min  mean[+/-sd] median   max     // 最小 平均 中位数  最大 
		Connect:        8   10   1.1     10      16
		Processing:    11  178  48.1    196     208
		Waiting:       10  115  56.0    114     205
		Total:          21  188  48.2    206     218
		
		Percentage of the requests served within a certain time (ms) // 看分位情况，避免出现极大值
		  50%    206
		  66%    208
		  75%    209
		  80%    213
		  90%    216
		  95%    217
		  98%    217
		  99%    218
		 100%    218 (longest request)