blocks|key|3269542|text|YouTube的目标页面渲染时间小于100ms+(Video+here+@7:00)。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3269543|您的瓶颈可能是数据库查询-尝试使用|3269544|EXPLAIN+select+*+from+x...|code-block|syntax|javascript|3269545|看看是否可以添加索引来加快查询速度。|3269546|编辑上面的链接已经死了。高可伸缩性在YouTube上实现了一个特性，该特性将视频用作其主要来源，因此它可能会引起一些兴趣：http://highscalability.com/youtube-architecture|style|BOLD|3269547|entityMap|0|LINK|mutability|MUTABLE|url|https://www.youtube.com/watch?v=w5WVu624fY8|1|http://highscalability.com/youtube-architecture^0|P|A|0|0|0|0|0|0|2|1P|1B|1|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|17|8|@$A|18|B|19|O|P]]|9|@$A|1A|B|1B|1|1C]]|C|$]]|$1|Q|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]|Y|$5|T|U|V|C|$W|Z]]]]

YouTube's target page rendering time is &lt; 100ms (<a href="https://www.youtube.com/watch?v=w5WVu624fY8" rel="nofollow noreferrer">Video here</a> @7:00).

Your bottleneck is probably DB queries - try using

<pre><code>EXPLAIN select * from x...
</code></pre>

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: <a href="http://highscalability.com/youtube-architecture" rel="nofollow noreferrer">http://highscalability.com/youtube-architecture</a>

blocks|key|3056316|text|它需要更快吗?为什么？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3056317|如果答案是“是，因为它在需求列表中”或“因为它占用了宝贵的服务器资源”，那么尝试优化您的SQL查询。也许你需要添加索引...|3056318|否则，我认为您应该继续下一项任务。首先，它是有效的，其次，您正在谈论的是.3+to+.5+sec。应该是fast+enough+for+humans和machines。|offset|length|3056319|entityMap|0|LINK|mutability|MUTABLE|url|http://www.useit.com/papers/responsetime.html^0|0|0|1G|M|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

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 <a href="http://www.useit.com/papers/responsetime.html" rel="nofollow noreferrer">fast enough for humans</a> and machines.

blocks|key|311636|text|在我看来有点高。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|311637|作为参考，我创建的框架的执行时间低至.0028，高达.0340秒。平均而言，每个页面通常有11+-+18个SQL查询。|311638|但是，请记住，这是一个高度优化的框架，利用了缓存、非常仔细的查询编码和自动加载。尝试实施这些策略，你应该会看到很大的进步。|311639|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|313400|text|使用PHP，大多数网站的生成速度如此之快，以至于最大的延迟是页面渲染，包括所有子请求，如显示图像。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|313401|而且访问者的互联网连接速度和质量、他的电脑和他的软件也是重要的因素。|313402|为了更加慷慨，我们假设PHP占用网页总负载和渲染时间的20%25。|313403|再说一次，我知道这个百分比非常接近，但它更多的是一个说明性的例子。|313404|平均页面加载时间约为3秒。(这太多了)高质量的网站应该需要大约1秒的时间来完全加载，所以PHP将被允许200ms+(1秒的20%25)来生成输出。所以php对于一个“一般”的网站可能需要600毫秒的时间。|313405|注意:可以通过更改主机或改进源代码来缩短PHP执行时间。|313406|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

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 &amp; 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.

blocks|key|313448|text|嗯..。我不确定绝对值在这里是不是很公平。这真的取决于硬件...当我在本地开发时，我的开发机器运行速度比实际服务器慢5-10倍。因此，如果我们取一个绝对值，“可接受”的范围将根据硬件的不同而有所不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|313449|嗯，通常我会尽量把时间控制在100毫秒以下。如果服务器加载时间更长，我将跟踪执行并尝试找出问题所在。我不得不说，大多数时候，数据库(因此查询)是瓶颈。这方面的真正工作是非常重要的。|313450|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|3269483|text|这当然是非常主观的，取决于网站等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3269484|然而，我要说的是，当一个页面开始花费超过100毫秒的时间时，这对用户来说是一个明显的延迟，这可能是“太长”。这是如果这是一个可以合理地预期瞬间加载的页面。如果页面是搜索页面，在大型数据库中执行全文搜索，情况当然会有所不同。|3269485|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

blocks|key|3055930|text|我会说再少10倍就可以了。不过，查询的数量并不重要。它们可能有20个，都运行了0.005秒。重要的是质量，而不是数量。分析您的代码以确定最慢的部分，通过添加更多的微时间语句，找到最慢的部分，然后对其进行优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3055931|如果您有自己用于查询mysql的函数，那么在其中放置microtime内容将非常方便|3055932|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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

blocks|key|3055988|text|这取决于前面所说的，但另外请考虑:在执行时间为一秒的情况下，您将能够(在理想情况下)在具有一个CPU的服务器计算机上每秒只能处理一个请求，并且该计算机上没有发生任何其他事情。如果传入的请求多于每秒一个，您将得到一个长队列，并且您的服务器将全速运行，从而导致处理传入请求的时间更长。如果你收到的请求较少，你仍然需要注意你的CPU利用率。如果服务器之前已经负载过重，您可能会遇到需要注意的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3055989|有一些数学方法(排队理论)可以用来分析容量需求，例如PDQ+(http://www.perfdynamics.com/Tools/PDQ.html)可以获得更多信息。|offset|length|3055990|因此，与Google相比可能并不公平，因为它们必须有大量的传入请求，并且随着执行时间增加3倍，它们需要的服务器将比现有的服务器多几倍……|3055991|entityMap|0|LINK|mutability|MUTABLE|url|http://www.perfdynamics.com/Tools/PDQ.html^0|0|V|16|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

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 (<a href="http://www.perfdynamics.com/Tools/PDQ.html" rel="nofollow noreferrer">http://www.perfdynamics.com/Tools/PDQ.html</a>) 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...

blocks|key|3056099|text|目标为<+200ms。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3056100|越来越多的人开始对耗时超过200ms的事情失去耐心。|3056101|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Aim for &lt; 200ms.

People increasingly start losing patience for tings that take > 200ms.

blocks|key|3056138|text|它们都是相对的，真的。不要期望获得与其他使用PHP的站点相同的时间。请记住，PHP需要在每次页面加载时从头开始加载所有内容。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3056139|你真的想看看你的网站在负载下有多好，比如使用Apache+ab来测试它。如果您的站点能够处理您所期望的最高流量级别，那么您就不需要再对其进行优化。用户将无法判断您的页面是在.75秒还是在.25秒内加载。|3056140|记住，调用microtime本身会增加页面加载的时间，因为它必须调用操作系统(上下文切换)。优化页面可能更有价值，使其更小，以便更快地通过网络，并在客户机上更快地呈现。|3056141|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|313492|text|我注意到，作为维基百科的一名编辑，在页面加载启动时间超过5到10秒之前，我们不会收到任何投诉。当然，对于大多数用户来说，报告这种缓慢的机制是模糊的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|313493|对于我自己来说--作为一个旅游网站的用户--中间的屏幕上写着“收到您的请求，正在处理中，可能需要X秒”，这足以让我感到欣慰。|313494|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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."

blocks|key|3269796|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3269797|我不会将你的脚本与谷歌进行比较，除非你在维护类似的页面排名。|unordered-list-item|3269798|如果搜索仅从数据库中检索值，则可以通过分析应用程序和消除瓶颈(提到一些页面上的脚本、大图像、大表、数据库索引)来提高速度|3269799|3269800|entityMap^0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|I|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|J|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|K|7|@]|8|@]|9|$]]|$1|F|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|M|7|@]|8|@]|9|$]]]|H|$]]

<ul>
<li>I wouldn't compare your script with Google, unless you're maintaining a similar page-ranking.. etc. </li>
<li>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)</li>
</ul>

blocks|key|3056404|text|我做了一个可湿性粉剂网站，在它的一个页面上运行着相当繁重的搜索和汇总统计数据的程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3056405|相应的PHP模块从数据库中获取大致的500记录，然后对每个记录进行解码，请求DB获取更多详细信息，比如10个不同的自定义字段，以聚合前端所需的所有补充数据。|offset|length|style|BOLD|3056406|然后，它只返回一页数据(比如20个项目)和统计信息(另外10个项目)。|3056407|查看我的Chrome开发工具计时|3056408|3056409|my+本地开发机器需要0.9-+1.1秒TTFB用于每个启动上述后端程序的XHR请求。|unordered-list-item|3056410|在一个相当好的共享主机上运行的真实web服务器需要0.3-0.6秒的|3056411|3056412|显然这不是干净的DB性能数字，Apache和PHP<->MySQL在时间上有障碍，但作为一个大致的数字，它是可以很好地使用的。这里没有SSL握手等连接开销。只是服务器准备数据和响应所用的时间，没有页面重新加载，也没有XHR请求。|3056413|如果所讨论的站点在高峰期有100访问者/小时在高峰期访问相同的数据库密集型页面，那么它只有~2个用户/分钟的，所以对于您的0.5秒/访问者请求，您可以为60个访问者/分钟的提供服务，并将其称为瓶颈。显然，在这种假想的情况下，空闲的性能容量是巨大的。|3056414|entityMap^0|0|I|5|1F|B|0|0|0|0|3|L|0|0|0|0|36|0|0|3G|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@$D|10|E|11|F|G]|$D|12|E|13|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|17|8|@$D|18|E|19|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|O|7|1A|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1C|8|@$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1F|8|@$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|X|$]]

I have made a WP site running rather heavy search &amp; 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 

<ul>
<li>my local dev machine needs ~0.9 - 1.1 sec for TTFB for each XHR request which initiates that backend procedure described above.</li>
<li>the real web server on a pretty good shared hosting for the same page requires 0.3-0.6 sec for TTFB.</li>
</ul>

Obviously this is not clean DB performance figure, Apache and PHP&lt;->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.

I am trying to figure out the efficiency of my server side code.

Using <code>microtime(true)</code> to measure speed, I am able to calculate the time it took my script to run.

I am getting average speeds of <code>.3</code> to <code>.5</code> 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 <code>.15</code> seconds and I feel like my script is crap.

What is considered a long execution time?

我正在尝试弄清楚我的服务器端代码的效率。使用microtime(true)测量速度，我可以计算出运行脚本所用的时间。我把.3的平均速度提高到了.5秒。这些脚本执行许多数据库查询，以向用户返回不同的值。网站在线运行的脚本的有效执行时间是多少？我知道这取决于正在执行的操作，但只需将其视为从数据库读取并将值返回给用户的标准脚本。我看着谷歌，看到他们在.15秒内搜索互联网，我觉得我的脚本就像垃圾一样。

问什么是较长的执行时间？
EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是较长的执行时间？EN

回答 13

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是较长的执行时间？
EN