我试图弄清楚我的服务器端代码的效率。
用于microtime(true)测量速度，我能够计算出我的脚本运行所花费的时间。
我的平均速度达到.3几秒.5。这些脚本执行许多数据库查询以向用户返回不同的值。
对于将为网站在线运行的 PHP 脚本，什么被认为是有效的执行时间？
我知道这完全取决于正在做什么，但只需考虑这是一个从数据库读取并将值返回给用户的标准脚本。我看着谷歌，看到他们在.15几秒钟内搜索互联网，我觉得我的脚本很垃圾。
问问题
11215 次
13 回答
9
YouTube 的目标页面渲染时间 < 100 毫秒（此处为视频@7:00）。
您的瓶颈可能是数据库查询 - 尝试使用
EXPLAIN select * from x...
看看你是否可以添加索引来加速你的查询。
编辑上面的链接已经死了。High Scalability 在 YouTube 上做了一个功能，使用该视频作为其主要来源，所以它可能会引起一些兴趣：http ://highscalability.com/youtube-architecture
于 2010-03-14T20:11:29.183 回答
3
它是否需要更快，为什么？
如果答案是“是的，因为它在需求列表中”或“因为它占用了宝贵的服务器资源”，那么请尝试优化您的 SQL 查询。也许您需要添加索引...
否则，我认为你应该继续下一个任务。首先，它有效，其次你说的是 0.3 到 0.5 秒。这对于人类和机器来说应该足够快。
于 2010-03-15T08:42:11.940 回答
3
对我来说似乎有点高。
作为参考，我创建的框架的执行时间低至 0.0028 秒，高至 0.0340 秒。平均而言，每个页面通常有 11 到 18 个 SQL 查询。
但是，请记住，这是一个高度优化的框架，利用缓存、非常仔细的查询编码和自动加载。尝试实施这些策略，您应该会看到很大的改进。
于 2014-07-21T20:47:18.453 回答
2
使用 PHP，大多数网站的生成速度都非常快，以至于最大的延迟是页面渲染，包括要显示的图像等所有子请求。
但访问者的互联网连接速度和质量、他的计算机和他的软件也是重要因素。
慷慨地说，假设 PHP 占用了网页总加载和渲染时间的 20%。
再说一次，我知道这个百分比是非常近似的，但更多的是一个说明性的例子。
平均页面加载时间约为 3 秒。（这太多了）高质量的网站应该需要大约 1 秒才能完全加载，因此 PHP 将被允许 200 毫秒（1 秒的 20%）来生成输出。因此，对于“平均”网站，php 最多可能需要 600 毫秒。
注意：PHP 执行时间可以通过更改主机或改进源代码来改进。
于 2010-03-14T20:10:04.900 回答
2
嗯...我不确定这里的绝对值是否公平。这真的取决于硬件......当我在本地开发时，我的开发机器运行速度比实际服务器慢 5-10 倍。因此，如果我们采用绝对值，“可接受”范围会因硬件而异。
好吧，通常我会尽量保持在 100 毫秒以下。如果服务器加载时间较长，我将跟踪执行并尝试找出问题所在。我不得不说大多数时候，数据库（因此是查询）是瓶颈。真正的工作非常重要。
于 2010-03-14T20:30:33.690 回答
1
这当然是非常主观的，取决于站点等。
但是，我会说当页面开始花费的时间超过 100 毫秒时，这对用户来说是一个明显的延迟，这可能是“太长了”。如果这是一个可以合理预期会立即加载的页面。如果页面是搜索页面，在大型数据库中做全文搜索，情况当然不同。
于 2010-03-14T19:48:41.433 回答
1
我会说少10倍就可以了。查询的数量并不重要。可以有 20 个，全部运行 0.005 秒。质量很重要，而不是数量。分析您的代码以确定最慢的部分，通过添加更多的微时间语句，找到最慢的部分，然后对其进行优化。
如果你有自己的查询 mysql 的函数，放置 microtime 的东西会非常方便
于 2010-03-14T20:11:16.503 回答
1
取决于，如上所述，但另外考虑这一点：一秒钟的执行时间，您将能够（在理想条件下）在具有一个 CPU 的服务器机器上每秒仅服务一个请求，并且没有其他任何事情发生机器。如果您的请求数超过每秒一个，您将排长队，并且您的服务器将完全耗尽，导致传入请求的处理时间更长。如果您收到的请求较少，您仍然需要注意您的 CPU 利用率。如果服务器之前已经负载过重，您可能会遇到需要处理的问题。
有一些数学方法（排队理论）可用于分析容量需求，请参阅例如 PDQ ( http://www.perfdynamics.com/Tools/PDQ.html ) 了解更多信息。
因此，与 Google 相比可能不公平，因为它们必须有大量的传入请求，并且执行时间要长 3 倍，它们需要的服务器数量是现有服务器的几倍……
于 2010-03-14T20:20:39.650 回答
1
瞄准 < 200 毫秒。
人们越来越多地开始对超过 200 毫秒的信号失去耐心。
于 2010-03-14T20:33:04.780 回答
1
这都是相对的，真的。不要期望获得与使用 PHP 的其他站点相同的时间。请记住，PHP 需要在每次页面加载时从头开始加载所有内容。
你真的想看看你的网站在负载下的表现如何，比如使用 Apache ab 来测试它。如果您的网站可以处理您所期望的最高流量水平，那么您就不需要再优化它了。用户无法判断您的页面是在 0.75 秒还是 0.25 秒内加载。
请记住，调用 microtime 本身会增加页面加载时间，因为它必须调用操作系统（上下文切换）。优化页面可能更有价值，使其更小，以便更快地通过网络并在客户端上更快地呈现。
于 2010-03-14T20:51:37.840 回答
1
我注意到，作为 Wikipedia 上的编辑，在页面加载启动超过 5 到 10 秒左右之前，我们不会看到投诉。当然，报告这种缓慢的机制对于大多数用户来说是模糊的。
对于我自己（作为旅游网站的用户）来说，中间屏幕显示“收到您的请求。它正在处理中。可能需要长达X秒”。
于 2010-03-14T20:56:42.697 回答
0
我不会将您的脚本与 Google 进行比较，除非您保持类似的页面排名......等。
如果搜索仅从数据库中检索值，则可以通过分析应用程序和消除瓶颈（仅举几例 - 页面脚本、大图像、大表、数据库索引）来提高速度
于 2010-03-15T07:49:32.773 回答
0
我已经制作了一个 WP 网站，在它的一个页面上运行相当繁重的搜索和汇总统计数据收集程序。
相应的 PHP 模块从数据库中获取大约500 条记录，然后解码每条请求数据库以获取更多详细信息，例如10 个不同的自定义字段，以聚合前端所需的所有免费数据。
然后它只返回一页数据（比如 20 个项目）和统计信息（另外 10 个项目）。
查看我的 Chrome 开发工具计时
- my local dev machine needs ~0.9 - 1.1 sec for TTFB for each XHR request which initiates that backend procedure described above.
- the real web server on a pretty good shared hosting for the same page requires 0.3-0.6 sec for TTFB.
Obviously this is not clean DB performance figure, Apache and PHP<->MySQL gets in the way of timing, but as ballpark figure it is well can be used. No SSL handshakes etc. connection overheads is presented here. Just the time server took to prepare the data and respond, no page reload as well as it is being an XHR request.
如果有问题的网站在高峰时段有100 名访问者/小时在高峰时段访问同一个 DB 密集型页面，则只有~2 个用户/分钟，因此通过您的 0.5 秒/访问者请求，您可以为60 名访问者/分钟提供服务并将其称为瓶颈。显然，在这种假想的情况下，备用性能容量是巨大的。
于 2019-01-24T15:10:14.937 回答