{"id":1428,"date":"2008-08-14T12:00:00","date_gmt":"2008-08-14T12:00:00","guid":{"rendered":"http:\/\/orcldoug.com\/blog\/?p=1428"},"modified":"2008-08-14T12:00:00","modified_gmt":"2008-08-14T12:00:00","slug":"time-matters-an-infinite-capacity-for-waiting","status":"publish","type":"post","link":"http:\/\/orcldoug.com\/blog\/2008\/08\/14\/time-matters-an-infinite-capacity-for-waiting\/","title":{"rendered":"Time Matters &#8211; An Infinite Capacity for Waiting*"},"content":{"rendered":"<p>When I was teaching the 10g Performance class at my last customer site, I remarked that the total number of seconds you see in the &#8220;Top 5 Timed Events&#8221; section of a Statspack or AWR report will often be greater than the total number of seconds between the snapshot intervals. For example, this is the &#8220;Top 5 Timed Events&#8221; section of a Statspack report covering two snapshots that are 5 minutes 30 seconds apart, either side of a 5 minute Sales Order Entry benchmark that I ran using <a href=\"http:\/\/dominicgiles.com\/swingbench.html\">Dominic Giles&#8217; Swingbench utility<\/a>.<\/p>\n<pre>Top 5 Timed Events\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Avg %Total\n~~~~~~~~~~~~~~~~~~\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 wait\u00a0\u00a0 Call\nEvent\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Waits\u00a0\u00a0\u00a0 Time (s)\u00a0\u00a0 (ms)\u00a0\u00a0 Time\n----------------------------------------- ------------ ----------- ------ ------\ndb file sequential read\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 5,814\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 461\u00a0\u00a0\u00a0\u00a0 79\u00a0\u00a0 38.0\nlog file sync\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 4,246\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 421\u00a0\u00a0\u00a0\u00a0 99\u00a0\u00a0 34.7\nlog file parallel write\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3,222\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 109\u00a0\u00a0\u00a0\u00a0 34\u00a0\u00a0\u00a0 9.0\nCPU time\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 108\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 8.9\ndb file parallel write\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1,718\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 60\u00a0\u00a0\u00a0\u00a0 35\u00a0\u00a0\u00a0 4.9<\/pre>\n<p>(Note that this is from a 10.2.0.4 Statspack report, but you would see something similar in all AWR reports and Statspack reports that include CPU time in this section.)<\/p>\n<p>Add up those seconds in the Time column and, even just for the top 5 events, the total is 1159 seconds or 19 minutes and 19 seconds. How can the system have spent 19 minutes and 19 seconds using CPU or waiting on various events when there were only 330 seconds in the reporting period? <\/p>\n<p>The person who asked me to clarify this after the training has seen a few Statspack reports in his time and understood that there is more CPU time available in a given period than the Wall Clock period because servers often have multiple CPUs. But, in this case, I ran the test on my laptop which has a dual-core CPU. Therefore the maximum CPU time available between these snapshots was 660 seconds, or 11 minutes.<\/p>\n<p>No, the real reason is that Statspack is <em>reporting system-wide event timings for more than one session and then aggregating them<\/em>. In this case, there were four user sessions running the SOE benchmark during the period. Given that each user and background session is instrumented and clocking up both service and wait time, aggregating the data for all of the sessions will record more time than has passed if you look at the clock on the wall.<\/p>\n<p>This is such an intuitive idea to me that I hadn&#8217;t thought to explain it properly during the course, so I set a mental reminder that I would blog about it soon. Having said that, this has been <a href=\"http:\/\/asktom.oracle.com\/pls\/asktom\/f?p=100:11:0::::P11_QUESTION_ID:3684814195679#13600970391654\">written about by others<\/a> on many occasions (<sup>*<\/sup>not least by <a href=\"http:\/\/carymillsap.blogspot.com\/\">Cary Millsap<\/a> and Jeff Holt in <a href=\"http:\/\/www.amazon.co.uk\/Optimizing-Oracle-Performance-Cary-Millsap\/dp\/059600527X\/ref=sr_1_1?ie=UTF8&amp;s=books&amp;qid=1218699840&amp;sr=8-1\">Optimizing Oracle Performance<\/a>. In fact, I stole the title of this blog post from their book &#8211; see page 215 for more information.) Therefore, if this post makes complete sense to you so far or you&#8217;ve read any of those sources before, continued reading will probably be a little boring. If not, this post is especially for you.<\/p>\n<p>So let&#8217;s revisit the tests. I ran two 5 minute tests using Swingbench&#8217;s supplied Sales Order Entry benchmark, but I could have used anything for this. The important thing is that the first test consisted of one session running the SOE application, while four sessions were running during the second test. <\/p>\n<p>Here is the top 5 timed events section of <a href=\"\/SOE1.txt\">the Statspack report for the single session test<\/a>.<\/p>\n<pre>Top 5 Timed Events\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Avg %Total\n~~~~~~~~~~~~~~~~~~\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 wait\u00a0\u00a0 Call\nEvent\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Waits\u00a0\u00a0\u00a0 Time (s)\u00a0\u00a0 (ms)\u00a0\u00a0 Time\n----------------------------------------- ------------ ----------- ------ ------\ndb file sequential read\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 4,818\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 175\u00a0\u00a0\u00a0\u00a0 36\u00a0\u00a0 46.3\nCPU time\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 57\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 15.2\ndb file parallel write\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1,085\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 42\u00a0\u00a0\u00a0\u00a0 39\u00a0\u00a0 11.2\nlog file sync\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 821\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 38\u00a0\u00a0\u00a0\u00a0 46\u00a0\u00a0 10.0\nlog file parallel write\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2,702\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 28\u00a0\u00a0\u00a0\u00a0 10\u00a0\u00a0\u00a0 7.5<\/pre>\n<p>&#8230; and from <a href=\"\/SOE4.txt\">the Statspack report for the four session test<\/a>.<\/p>\n<pre>Top 5 Timed Events\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Avg %Total\n~~~~~~~~~~~~~~~~~~\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 wait\u00a0\u00a0 Call\nEvent\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Waits\u00a0\u00a0\u00a0 Time (s)\u00a0\u00a0 (ms)\u00a0\u00a0 Time\n----------------------------------------- ------------ ----------- ------ ------\ndb file sequential read\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 5,814\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 461\u00a0\u00a0\u00a0\u00a0 79\u00a0\u00a0 38.0\nlog file sync\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 4,246\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 421\u00a0\u00a0\u00a0\u00a0 99\u00a0\u00a0 34.7\nlog file parallel write\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3,222\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 109\u00a0\u00a0\u00a0\u00a0 34\u00a0\u00a0\u00a0 9.0\nCPU time\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 108\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 8.9\ndb file parallel write\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1,718\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 60\u00a0\u00a0\u00a0\u00a0 35\u00a0\u00a0\u00a0 4.9<\/pre>\n<p>So the two tests were running the same application, on the same hardware and for the same duration. Yet the values in the Time (s) column are much bigger when more sessions are running. The total for just the top 5 timed events is 340 seconds compared to 1159 seconds. (The average wait times have also increased in some cases, because the system is busier, and different events become more significant as concurrent sessions contend with each other. There are various things we could <em>try<\/em> to deduce from this section, particularly as this was a controlled test, but we&#8217;d need more supporting information. Let&#8217;s just stick to the apparently increased time.)<\/p>\n<p>The problem here, if you see it as a problem, is that aggregated data is being reported. Statspack is not the only example of this, though. Tracing Parallel Execution tasks and then aggregating the trace files using trcsess into one consolidated trace file will also result in variable timings, depending on the Degree of Parallelism. I talked about this in slides 33 to 37 of <a href=\"http:\/\/www.slideshare.net\/dougburns\/tracing-parallel-execution-ukoug-2006\">an earlier presentation<\/a>. In fact, I can make the Time (s) values as big as I want to, just by running the SOE benchmark with more and more sessions.<\/p>\n<p>That&#8217;s why the % Total Call Time is a far more useful column. It tells you the system-wide percentage contribution of each event to any performance problem over the given period so that you can focus on the most significant contributors. It should go without saying that looking at session-level statistics is more specific and therefore more reliable but that&#8217;s not always possible unless you&#8217;re using ASH, Kyle Hailey&#8217;s Simulated ASH, some other session history recorder or can recreate the problem session on demand, but that&#8217;s another, bigger argument that I won&#8217;t go into here.<\/p>\n<p>So if wall clock time for those tests was about 300 seconds, then what <em>is<\/em> that bigger value being recorded in the Time (s) column? What I&#8217;m really talking about is DB Time, but I&#8217;ll leave that for the next post.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When I was teaching the 10g Performance class at my last customer site, I remarked that the total number of seconds you see in the &#8220;Top 5 Timed Events&#8221; section of a Statspack or AWR report will often be greater than the total number of seconds between the snapshot intervals. For example, this is the&hellip; <a class=\"more-link\" href=\"http:\/\/orcldoug.com\/blog\/2008\/08\/14\/time-matters-an-infinite-capacity-for-waiting\/\">Continue reading <span class=\"screen-reader-text\">Time Matters &#8211; An Infinite Capacity for Waiting*<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1428","post","type-post","status-publish","format-standard","hentry","category-uncategorized","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":1429,"url":"http:\/\/orcldoug.com\/blog\/2008\/08\/20\/time-matters-db-time\/","url_meta":{"origin":1428,"position":0},"title":"Time Matters &#8211; DB Time","date":"August 20, 2008","format":false,"excerpt":"[In retrospect, the title of that first blog post might have suited the subject, but doesn't translate too well for subsequent related blog posts. That was a lack of planning or foresight on my part. These blog posts are tumbling out of my head in a fairly incoherent way. Maybe\u2026","rel":"","context":"With 13 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1156,"url":"http:\/\/orcldoug.com\/blog\/2006\/12\/07\/a-more-complex-statspack-example-part-2\/","url_meta":{"origin":1428,"position":1},"title":"A More Complex Statspack Example &#8211; Part 2","date":"December 7, 2006","format":false,"excerpt":"So far we're barely into the comparison of the Statspack reports from the two different test environments and they look quite different already.Next up, the Instance Efficiency Percentages. I have to confess that I rarely find these very useful because the numbers are always near 100% on most databases I\u2026","rel":"","context":"With 13 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1153,"url":"http:\/\/orcldoug.com\/blog\/2006\/12\/01\/a-small-statspack-success\/","url_meta":{"origin":1428,"position":2},"title":"A Small Statspack Success","date":"December 1, 2006","format":false,"excerpt":"I'll warn you up front that this is going to be spectacularly lacking in detail but it's a simple and true example from the other week of the kind of thing I find Statspack useful for.One of the developers scuttled round to my desk one late shift very concerned about\u2026","rel":"","context":"With 7 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1719,"url":"http:\/\/orcldoug.com\/blog\/2014\/07\/24\/recurring-conversations-awr-intervals-part-2\/","url_meta":{"origin":1428,"position":3},"title":"Recurring Conversations: AWR Intervals (Part 2)","date":"July 24, 2014","format":false,"excerpt":"(Reminder, just in case we still need it, that the use of features in this post require Diagnostics Pack license.) Damn me for taking so long to write blog posts these days. By the time I get around to them, certain very knowledgeable people have commented on part 1 and\u2026","rel":"","context":"Similar post","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1159,"url":"http:\/\/orcldoug.com\/blog\/2006\/12\/11\/a-more-complex-statspack-example-summary\/","url_meta":{"origin":1428,"position":4},"title":"A More Complex Statspack Example &#8211; Summary","date":"December 11, 2006","format":false,"excerpt":"Looking back at the three blogs (and hopefully the comments, where others have made some very useful contributions), it's all quite unsatisfactory, isn't it? We haven't solved the problem. All we've proved is that the tests aren't equivalent, although I think there's value in that negative result because I was\u2026","rel":"","context":"With 3 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1155,"url":"http:\/\/orcldoug.com\/blog\/2006\/12\/06\/a-more-complex-statspack-example-part-1\/","url_meta":{"origin":1428,"position":5},"title":"A More Complex Statspack Example &#8211; Part 1","date":"December 6, 2006","format":false,"excerpt":"Following on from the last Statspack example, up popped an example at work this week of another common reason I use Statspack - comparing the performance of different environments. It's also a nice illustration of some of Statspack's limitations.Because a Statspack report contains a lot of information and this particular\u2026","rel":"","context":"With 8 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1428","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/comments?post=1428"}],"version-history":[{"count":0,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1428\/revisions"}],"wp:attachment":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/media?parent=1428"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/categories?post=1428"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/tags?post=1428"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}