我正在使用一种 code_ping 来处理整个页面以及我的门户网站中的所有页面。
我想如果我在使用当前时间戳初始化的标头中执行 $count_start 并在页脚中执行 $count_end ，同样，差异是一个米，可以大致让我知道页面的优化程度（查询，所有事物的加载时间在该特定页面中）。
说一页我得到 0.0075 秒，对于其他我得到 0.045 等......我正在努力以这种方式更好地优化查询。
我的问题是。如果一个页面通过这个仪表显示“粗略加载时间”有 0.007 秒，那么 1000 个用户同时查询同一页面会在 0.007 * 1000 = 7 秒内得到每个结果吗？这意味着他们每个人都会在 7 秒后获得该页面？
谢谢
幸运的是，它通常不是这个意思。
您的等式中缺少的变量是您的数据库和应用程序服务器以及堆栈中的任何其他内容如何处理并发。
为了从 MySQL 的角度严格说明这一点，我编写了一个测试客户端程序，它与 MySQL 服务器建立固定数量的连接，每个连接都在自己的线程中（因此，能够大致同时向服务器发出查询） .
一旦所有线程都发回信号表明它们已连接，则会同时向所有线程发送一条消息，以发送它们的查询。
当每个线程收到“go”信号时，它会查看当前系统时间，然后将查询发送到服务器。当它得到响应时，它再次查看系统时间，然后将所有信息发送回主线程，主线程比较时间并生成下面的输出。
该程序的编写方式是它不计算建立与服务器的连接所需的时间，因为在性能良好的应用程序中，连接是可重用的。
查询是SELECT SQL_NO_CACHE COUNT(1) FROM ...（一个包含大约 500 行的 InnoDB 表）。
threads 1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads 2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads 4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads 8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841
时间以秒为单位。min/max/avg 是观察到运行相同查询的最佳/最差/平均时间。在 64 次并发时，您注意到最佳情况与只有 1 个查询的最佳情况并没有什么不同。但这里最大的收获是总运行时间列。该值是与第一个线程发送查询时的时间差（它们基本上都在同一时间发送查询，但“精确”同一时间是不可能的，因为我没有 64 核机器来运行测试脚本打开）到最后一个线程收到其响应的时间。
观察：好消息是平均耗时 0.005586 秒的 64 个查询绝对不需要 64 * 0.005586 秒 = 0.357504 秒来执行......它甚至不需要 64 * 0.001089（最佳情况时间）= 0.069696 全部这些查询中有一些是在 0.019841 秒内开始和完成的……或者说只有理论上它们一个接一个运行所需时间的大约 28.5%。
当然，坏消息是，这个查询在 64 并发下的平均执行时间是它只运行一次的时间的 5 倍多……而最坏的情况几乎是 14 倍。但这仍然比从单个查询执行时间进行的线性推断要好得多。
不过，事情不会无限扩展。正如您所看到的，性能确实会随着并发而恶化，并且在某些时候它会走下坡路——可能相当快——因为我们遇到了首先出现的瓶颈。表的数量、查询的性质、遇到的任何锁定都会影响服务器在并发负载下的性能，以及存储性能、系统内存的大小、性能和架构，以及MySQL 的内部结构——有些可以调整，有些不能。
但当然，数据库并不是唯一的因素。应用程序服务器处理并发请求的方式可能是负载下性能的另一个重要部分，有时比数据库更大，有时更少。
您的基准测试中有一个很大的未知数是数据库回答查询花费了多少时间，应用程序服务器执行逻辑业务花费了多少时间，以及代码花费了多少时间将页面结果呈现为 HTML。