什么被认为是长执行时间？
我想弄清楚我的服务器端代码的效率。
使用 microtime(true) 来测量速度，我能够计算脚本运行所需的时间。
我的平均速度为 .3 到 .5 秒。这些脚本执行许多数据库查询以将不同的值返回给用户。
对于网站在线运行的 PHP 脚本来说，什么被认为是有效的执行时间？
我知道这取决于正在做什么，但只需考虑这是一个从数据库读取的标准脚本，将值返回给用户。我查看 Google，看到他们在 .15 秒内搜索互联网，我觉得我的脚本很糟糕。
I am trying to figure out the efficiency of my server side code.
Using microtime(true) to measure speed, I am able to calculate the time it took my script to run.
I am getting average speeds of .3 to .5 seconds. These scripts do a number of database queries to return different values to the user.
What is considered an efficient execution time for PHP scripts that will be run online for a website?
I know it depends on exactly what is being done, but just consider this a standard script that reads from a database and returns values to the user. I look at Google and see them search the internet in .15 seconds and I feel like my script is crap.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
YouTube 的目标页面呈现时间<< 100 毫秒（视频 @7:00）。
您的瓶颈可能是数据库查询 - 尝试使用
看看是否可以添加索引来加快查询速度。
编辑上面的链接已失效。 High Scalability 在 YouTube 上做了一项功能，使用该视频作为其主要来源，因此可能会引起一些兴趣：http: //highscalability.com/youtube-architecture
YouTube's target page rendering time is < 100ms (Video here @7:00).
Your bottleneck is probably DB queries - try using
to see if you can add indexes that will speed up your queries.
edit the link above has died. High Scalability did a feature on YouTube that used that video as its primary source, so it may be of some interest: http://highscalability.com/youtube-architecture
嗯...我不确定这里的绝对值是否相当公平。这确实取决于硬件......当我在本地开发时，我的开发者机器的运行速度比实际服务器慢 5-10 倍。
因此，如果我们取绝对值，“可接受”的范围将根据硬件的不同而有所不同。
嗯，一般来说我会尽量将时间控制在 100 毫秒以下。如果服务器加载时间较长，我将跟踪执行情况并尝试找出问题所在。我不得不说，大多数时候，数据库（因此查询）是瓶颈。对此进行真正的研究非常重要。
Hum... I'm not sure an absolute value is quite fair here. It really depends on the hardware... When I develop locally, my developper machine runs something like 5-10 times slower than the actuel server.
So if we take an absolute value, the "acceptable" range would vary depending on the hardware.
Well, generally I try to keep things below 100 ms. If the server load time is higher, I'll trace the execution and try to figure out what's wrong. I have to say most of the time, the databse (hence the queries) are the bottleneck. A real work on that is really important.
对我来说似乎有点高。
作为参考，我创建的框架的执行时间低至 0.0028 秒，高达 0.0340 秒。平均而言，每个页面通常有 11 - 18 个 SQL 查询。
但是，请记住，这是一个高度优化的框架，利用缓存、非常仔细的查询编码和自动加载。尝试实施这些策略，您应该会看到很大的进步。
Seems a bit high to me.
For reference, my framework that I've created is getting execution times as low as .0028 and as high as .0340 seconds. On average, each page typically has between 11 - 18 SQL queries.
However, keep in mind that this is a highly optimized framework, taking advantage of caching, very careful coding of queries, and autoloading. Try implementing those tactics, and you should see a big improvement.
是否需要更快，为什么？
如果答案是“是的，因为它在要求列表中”或“因为它需要宝贵的服务器资源”，那么请尝试优化您的 SQL 查询。也许您需要添加索引...
否则，我认为您应该继续执行下一个任务。首先，它有效，其次你正在谈论 0.3 到 0.5 秒。对于人类和机器来说，它应该足够快。
Does it need to be faster and why?
If the answer is "Yes, because it's on the requirements list" or "Because it takes valuable server resources", then try to optimize your SQL queries. Maybe you need to add index(es)...
Otherwise, I think you should move on to the next task. First, it works and second you are talking about .3 to .5 sec. which should be fast enough for humans and machines.
使用 PHP，大多数网站的生成速度非常快，最大的延迟是页面渲染，包括所有子请求，例如要显示的图像。
但访问者的互联网连接速度和质量、他的计算机和软件也是重要因素。
慷慨地说，假设 PHP 占用了总负载的 20%。网页的渲染时间。
再说一遍，我知道这个百分比是非常近似的，但它更多的是作为说明性示例。
平均页面加载时间约为 3 秒。 （太多了）
高质量的网站应该需要大约 1 秒才能完全加载，因此 PHP 将有 200 毫秒（1 秒的 20%）来生成输出。
因此，对于“普通”网站来说，php 可能需要长达 600 毫秒的时间。
注意：可以通过更改主机或改进源代码来缩短 PHP 执行时间。
With PHP, most websites are generated so fast that the biggest delay is the page rendering, including all sub-requests such as images to display.
But also the visitor's internet connection speed and quality, his computer and his software are important factors.
To be generous, let's say PHP takes 20% of the total load & rendering time of a web page.
And again, I know this percentage is very approximative, but it's more for an illustrative example.
An average page loading time is around 3 seconds. (which is too much)
Good quality websites should take about 1 second to be fully loaded, so PHP will be allowed 200ms (20% of 1 sec) to generate the output.
So php could take up to 600ms for an "average" website.
Note: The PHP execution time can be improved by changing your hoster, or by improving your source code.
这当然是非常主观的，取决于站点等。
但是，我想说，当页面开始花费超过 100 毫秒左右的时间时，对于用户来说这是一个明显的延迟，并且可能“太长” 。也就是说，如果这是一个可以合理预期立即加载的页面。如果页面是搜索页面，在大型数据库中进行全文搜索，情况当然不同。
This is of course very subjective, depends on the site, etc. etc.
However, I'd say that when a page starts taking longer than around 100 milliseconds, it's a noticeable delay for the user, and that might be "too long". That's if this is a page that can reasonably be expected to load instantaneously. If the page is a search page, doing a fulltext search in a large database, the situation is of course different.
我想说减少10倍就可以了。
但查询的数量并不重要。可以有 20 个，全部运行 0.005 秒。质量很重要，而不是数量。
分析您的代码以确定最慢的部分，通过添加更多微时间语句，找到最慢的部分，然后对其进行优化。
如果你有自己的查询mysql的函数，在那里放置microtime的东西会非常方便
I'd say 10 times less would be ok.
The number of queries doesn't matter though. There can be 20 of them, all running for 0.005 sec. The quality does matter, not the quantity.
Profile your code to determine most slow parts, by adding some more microtime statements, find a most slow part and then optimize it.
If you have your own function for query mysql, to place microtime stuff there would be very handy
如前所述，取决于情况，但另外请考虑这一点：执行时间为一秒，您将能够（在理想条件下）在具有一个 CPU 的服务器计算机上每秒仅处理一个请求，并且该服务器上没有发生任何其他事情机器。如果每秒传入的请求多于一个，那么您的队列将会很长，并且您的服务器将全力运行，导致传入的请求需要更长的时间来处理。如果您收到的请求较少，您仍然需要注意 CPU 利用率。如果服务器之前已经负载过重，那么您可能会遇到需要注意的问题。
有一些数学方法（排队论）可用于分析容量需求，例如 PDQ ( http://www.perfdynamics.com/Tools/PDQ.html）了解更多信息。
因此，与 Google 相比可能不公平，因为他们必须有大量传入请求，并且执行时间要长 3 倍，他们需要的服务器数量是现有服务器的数倍......
Depends, like stated, but in addition consider this: with a one second execution time, you will be able to serve (under ideal conditions) only one request per second on a server machine with one CPU and where there is nothing else happening on that machine. If you have more requests than one per second coming in, you will get a long queue, and your server will run flat out, causing incoming requests to take even longer to process. If you get less requests you still need to pay attention to your CPU utilization. If the server is heavily loaded already before, you may have a problem that need to be attended to.
There are mathematical methods (queueing theory) that can be used to analyze capacity requirements, see for example PDQ (http://www.perfdynamics.com/Tools/PDQ.html) for more.
Comparing to Google may not hence be fair, since they must have massive amounts of incoming requests, and with 3 times longer execution time they would need several times more servers than they already have...
目标是< 200毫秒。
人们越来越开始对那些需要 > 的事情失去耐心。 200毫秒。
Aim for < 200ms.
People increasingly start losing patience for tings that take > 200ms.
这真的都是相对的。不要期望获得与其他使用 PHP 的网站相同的时间。请记住，PHP 需要在每次页面加载时从头开始加载所有内容。
实际上，您想了解站点在负载下的表现如何，例如使用 Apache ab 来测试它。如果您的网站可以处理您期望的最高流量水平，那么您就不需要再对其进行优化。用户无法判断您的页面加载时间是 0.75 秒还是 0.25 秒。
请记住，调用 microtime 本身会增加页面加载时间，因为它必须调用操作系统（上下文切换）。优化页面可能更有价值，使其更小，以便更快地通过网络并在客户端上更快地呈现。
It's all relative, really. Don't expect to get times on par with other sites using PHP. Remember, PHP needs to load everything from scratch on each page load.
Really you want to see how well your site does under load, like using Apache ab to test it. If your site can handle the highest traffic level you can expect, then you don't need to optimize it anymore. A user isn't going to be able to tell if your page loads in .75 seconds or .25 seconds.
Remember, calling microtime itself is going to add time to your page load since it has to make a call out to the operating system (context switch). It may be more valuable to optimize the page, making it smaller so it goes over the network faster and renders faster once on the client.
我注意到，作为维基百科的编辑，我们只有在页面加载启动超过 5 到 10 秒左右时才会看到投诉。当然，大多数用户都不清楚报告这种缓慢情况的机制。
对于我自己（作为旅游网站的用户）来说，中间屏幕显示“已收到您的请求。正在处理。可能需要长达 X 秒”，这足以让我感到安心。
I notice that, as an editor on Wikipedia, we don't see complaints until page load initiation exceeds somewhere around 5 to 10 seconds. Of course the mechanism for reporting such slowness is obscure to most users.
For myself—as a user of travel websites—I am adequately placated by an intermediate screen which says "Got your request. It's now processing. It might take up to X seconds."
我不会将你的脚本与 Google 进行比较，除非你保持类似的页面排名.. 等。
如果搜索仅从数据库中检索值，则速度可能会通过以下方式提高一些
分析应用程序并消除瓶颈（仅举几例 - 页面上的脚本、大图像、大表、数据库索引）
I wouldn't compare your script with Google, unless you're maintaining a similar page-ranking.. etc.
If the search merely retrieves values from a database the speed may be improved some by
profiling the application and eliminating bottle-necks (to mention a few - script on page, large images, large tables, database indexes)
我做了一个 WP 网站，运行相当繁重的搜索和搜索。在其页面之一上汇总统计数据收集程序。
相应的 PHP 模块从数据库中获取大约500 条记录，然后对每个请求数据库的记录进行解码，以获取10 个不同自定义字段的更多详细信息，以聚合该数据库所需的所有补充数据。前端。
然后它只返回一页数据（比如 20 项）和统计信息（另外 10 项）。
查看我的 Chrome 开发工具，
显然，这不是干净的数据库性能数据，Apache 和 PHP<->MySQL 会妨碍计时，但作为大概的数据，它是可以使用的。这里没有 SSL 握手等连接开销。只是服务器准备数据和响应所花费的时间，没有页面重新加载，而且它是一个 XHR 请求。
如果相关网站在高峰时段有100 位访问者/小时在高峰时段访问同一数据库密集型页面，则只有~2 位用户/分钟，因此根据您的 0.5 秒/访客请求，您可以为 60 位访客/分钟提供服务，并将其称为瓶颈。显然，在这种假想的情况下，备用性能容量是巨大的。
I have made a WP site running rather heavy search & aggregated statistics gathering procedure on one of its pages.
The respective PHP module gets roughly 500 records from the DB and then decodes each one requesting DB for more details for say 10 different custom fields to aggregate all the required complimentary data for the front-end.
Then it returns only a page of data (say 20 items) and the statistics info (another 10 items).
Looking at my Chrome dev tools timing
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.
If the site under question in a peak hour has 100 visitors / hour visiting that same DB-heavy page in a peak hour, it is only ~2 users / minute, so with your 0.5 sec / visitor request you could serve 60 visitors / minute and call it the bottleneck. Obviously the spare performance capacity is huge in this imaginary case.