0

私のウェブサイトは AWS EC2 上にあります。

次のコマンドで TTFB (Time to First Byte) を確認しました。

curl --output /dev/null --silent --write-out "time_namelookup=%{time_namelookup}\ntime_connect=%{time_connect}\ntime_appconnect=%{time_appconnect}\ntime_pretransfer=%{time_pretransfer}\ntime_redirect=%{time_redirect}\ntime_starttransfer=%{time_starttransfer}\ntime_total=%{time_total}\n" --url http://13.37.46.163/

コンピューターでコマンドを実行したときの結果は次のとおりです。

time_connect=0,014614
time_appconnect=0,000000
time_pretransfer=0,014657
time_redirect=0,000000
time_starttransfer=0,119092
time_total=0,134436

Web サーバー自体でコマンドを実行した結果は次のとおりです。

time_namelookup=0.000058
time_connect=0.001296
time_appconnect=0.000000
time_pretransfer=0.001336
time_redirect=0.000000
time_starttransfer=0.084576
time_total=0.085031

どちらの場合も、最長の時間は time_starttransfer であることに気付きました。この時間を短縮するにはどうすればよいですか？

time_starttransfer とは何ですか?

開始から最初のバイトが転送される直前までにかかった時間 (秒単位)。これには、time_pretransfer と、サーバーが結果を計算するのに必要な時間が含まれます。

私のウェブサイトの設定

私のウェブサイトのリンクは: http://13.37.46.163/

EC2 + ServerPilot + PHP7で動くGrav CMS witchです

Amazon マシン イメージ (AMI)
Ubuntu Server 20.04 LTS (HVM)、EBS 汎用 (SSD) ボリューム タイプ。64 ビット (x86)

EC2 インスタンスタイプ
t2.micro

Web サーバー
Nginx

プログラム言語
PHP

リバース プロキシ
Nginx

キャッシュ ここで確認できるように、有効になっているOpcache
を既に使用しています: http://13.37.46.163/info.php#module_zend+opcache

CDNについては、既に Grav CDN Plugin を使用しています。( https://github.com/getgrav/grav-plugin-cdn )

私のウェブサイトのログ (リクエスト/分)

  1 00:02
  1 00:38
  1 00:54
  1 01:06
  1 01:12
  1 01:23
  1 03:49
  1 04:32
  1 04:57
  6 05:15
  1 05:17
  1 05:31
  1 05:37
  1 06:08
  1 06:32
  1 07:30
  1 07:38
  1 07:55
  1 08:31
  1 10:07
  1 10:35
  1 10:52
  1 10:59
  1 12:53
  1 13:00
  1 14:18
  1 14:28
  1 14:29
  1 14:48
  1 16:05
  1 18:40
  1 19:20
  1 20:24
  1 20:30

つまり、平均して 1 リクエスト/分

実施されたテスト

  1. PHP がホストしていない静的ファイルに対して TTFB テストを実行しようとしています

「main.js」ファイルで TTFB テストを実行しました。

結果は次のとおりです。

time_namelookup=0.000034
time_connect=0.002659
time_appconnect=0.000000
time_pretransfer=0.002702
time_redirect=0.000000
time_starttransfer=0.003983
time_total=0.004026

結果の分析:
結果は満足しています (time_starttransfer=0.003983)。しかし、この結果は、サイト全体に比べてファイルの重量が軽いためだと思います。問題はNGINXではなくPHP側にあると推測できます。

  1. 何が実行されているか、何がリソースを使用しているかを確認するための実行topとfreeコマンド、何が不要ですか?

topコマンドの結果は次のとおりです。

+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
| %Cpu(s):  | 4.0 us,      | 0.3 sy,     | 0.0 ni,     | 95.7 id,         | 0.0 wa, | 0.0 hi, | 0.0 si, | 0.0 st |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
| MiB Mem : | 978.6 total, | 75.8 free,  | 332.2 used, | 570.6 buff/cache |         |         |         |        |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+
| MiB Swap: | 512.0 total, | 427.2 free, | 84.8 used.  | 461.7 avail Mem  |         |         |         |        |
+-----------+--------------+-------------+-------------+------------------+---------+---------+---------+--------+

CPU % を確認するために Web サイトをリロードしたときに結果を取得しました。

freeコマンドの結果は次のとおりです。

+-------+---------+--------+--------+--------+------------+-----------+
|       | total   | used   | free   | shared | buff/cache | available |
+-------+---------+--------+--------+--------+------------+-----------+
| Mem:  | 1002052 | 334392 | 83368  | 16940  | 584292     | 478628    |
+-------+---------+--------+--------+--------+------------+-----------+
| Swap: | 524284  | 86784  | 437500 |        |            |           |
+-------+---------+--------+--------+--------+------------+-----------+

結果の分析:
使用しないほうがよいかもしれませt3.microんt2.micro- わずかに速く、わずかに安価です。(?)

4

2 に答える 2