代码 ping 计时表 - 这是真的吗? [英] code ping time meter - is this really true?

问题描述

我正在使用一种 code_ping 来处理整个页面，以及我的门户网站中的所有页面.

I am using a sort of code_ping for the time it took to process the whole page, to all my pages in my webportal.

我想如果我在用当前时间戳初始化的标题中执行 $count_start 并在页脚中执行 $count_end ，相同的，差异是一个米，粗略地让我知道页面的优化程度(查询，加载时间该特定页面中的所有内容).

I figured if I do a $count_start in the header initialised with current timestamp and a $count_end in the footer, the same, the difference is a meter to roughly let me know how well optimised the page is (queries, loading time of all things in that particular page).

比如说，对于一个页面，我得到 0.0075 秒，对于其他页面，我得到 0.045 秒等等......我正在努力以这种方式更好地优化查询.

Say for one page i get 0.0075 seconds, for others I get 0.045 etc...i'm working on optimising the queries better this way.

我的问题是.如果一个页面通过这个仪表显示粗略加载时间"有 0.007 秒，1000 个用户同时查询同一页面会在 0.007 * 1000 = 7 秒内得到每个结果吗?意思是他们每个人都会在 7 秒后获得页面?

My question is. If one page says by this meter "rough loading time" that has 0.007 seconds, will 1000 users querying the same page at the same time get each the result in 0.007 * 1000 = 7 seconds ? meaning they will each get the page after 7 seconds ?

谢谢

推荐答案

幸运的是，通常情况并非如此.

Luckily, it doesn't usually mean that.

等式中缺少的变量是您的数据库和您的应用服务器和堆栈中的任何其他内容如何处理并发.

The missing variable in your equation is how your database and your application server and anything else in your stack handles concurrency.

为了从 MySQL 的角度严格说明这一点，我编写了一个测试客户端程序，该程序建立到 MySQL 服务器的固定数量的连接，每个连接都在自己的线程中(因此，能够在大约同时).

To illustrate this strictly from the MySQL perspective, I wrote a test client program that establishes a fixed number of connections to the MySQL server, each in its own thread (and so, able to issue a query to the server at approximately the same time).

一旦所有线程都发回它们已连接的信号，就会同时向所有线程发送一条消息，以发送它们的查询.

Once all of the threads have signaled back that they are connected, a message is sent to all of them at the same time, to send their query.

当每个线程得到go"信号时，它会查看当前系统时间，然后将查询发送到服务器.当它得到响应时，它再次查看系统时间，然后将所有信息发送回主线程，主线程比较时间并生成下面的输出.

When each thread gets the "go" signal, it looks at the current system time, then sends the query to the server. When it gets the response, it looks at the system time again, and then sends all of the information back to the main thread, which compares the timings and generates the output below.

程序的编写方式不计算与服务器建立连接所需的时间，因为在行为良好的应用程序中，连接是可重用的.

The program is written in such a way that it does not count the time required to establish the connections to the server, since in a well-behaved application the connections would be reusable.

查询是 SELECT SQL_NO_CACHE COUNT(1) FROM ...(一个包含大约 500 行的 InnoDB 表).

The query was SELECT SQL_NO_CACHE COUNT(1) FROM ... (an InnoDB table with about 500 rows in it).

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 核机器来运行测试脚本)到最后一个线程收到响应时.

Times are in seconds. The min/max/avg are the best/worst/average times observed running the same query. At a concurrency of 64, you notice the best case wasn't all that different than the best case with only 1 query. But biggest take-away here is the total runtime column. That value is the difference in time from when the first thread sent its query (they all send their query at essentially the same time, but "precisely" the same time is impossible since I don't have a 64-core machine to run the test script on) to when the last thread received its response.

观察:好消息是，平均耗时 0.005586 秒的 64 个查询绝对不需要 64 * 0.005586 秒 = 0.357504 秒来执行......它甚至不需要 64 * 0.001089(最佳情况时间)= 0.069696 所有这些查询都是在 0.019841 秒内开始和完成的……或者说，它们在理论上一个接一个地运行所需的时间只有大约 28.5%.

Observations: the good news is that the 64 queries taking an average of 0.005586 seconds definitely did not require 64 * 0.005586 seconds = 0.357504 seconds to execute... it didn't even require 64 * 0.001089 (the best case time) = 0.069696 All of those queries were started and finished within 0.019841 seconds... or only about 28.5% of the time it would have theoretically taken for them to run one-after-another.

当然，坏消息是这个查询在并发为 64 时的平均执行时间是它只运行一次的时间的 5 倍以上……而最坏的情况几乎是它的 14 倍高的.但这仍然比根据单查询执行时间进行线性推断所建议的要好得多.

The bad news, of course, is that the average execution time on this query at a concurrency of 64 is over 5 times as high as the time when it's only run once... and the worst case is almost 14 times as high. But that's still far better than a linear extrapolation from the single-query execution time would suggest.

不过，事情不会无限期地扩展.正如您所看到的，性能确实会随着并发而下降，并且在某个时候它会走下坡路——可能相当快——因为我们到达了最先出现的瓶颈.表的数量、查询的性质、遇到的任何锁定，都会影响服务器在并发负载下的性能，存储的性能、系统内存的大小、性能和体系结构，以及MySQL 的内部结构——有些可以调整，有些不能.

Things don't scale indefinitely, though. As you can see, the performance does deteriorate with concurrency and at some point it would go downhill -- probably fairly rapidly -- as we reached whichever bottleneck occurred first. The number of tables, the nature of the queries, any locking that is encountered, all contribute to how the server performs under concurrent loads, as do the performance of your storage, the size, performance, and architecture, of the system's memory, and the internals of MySQL -- some of which can be tuned and some of which can't.

当然，数据库并不是唯一的因素.应用服务器处理并发请求的方式可能是负载下性能的另一个重要组成部分，有时比数据库更大，有时则更少.

But of course, the database isn't the only factor. The way the application server handles concurrent requests can be another big part of your performance under load, sometimes to a larger extent than the database, and sometimes less.

您的基准测试中有一个很大的未知数是数据库回答查询花费了多少时间，应用服务器执行逻辑业务花费了多少时间，以及应用服务器花费了多少时间将页面结果呈现为 HTML 的代码.

One big unknown from your benchmarks is how much of that time is spent by the database answering the queries, how much of the time is spent by the application server executing the logic business, and how much of the time is spent by the code that is rendering the page results into HTML.

这篇关于代码 ping 计时表 - 这是真的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！