-7

I have enabled a PHP profiler, well magento, but it is still a profiler. This is the standard magento compiler that records all the processing including all db queries to create the page, from receiving the request.

mage-profiler

I am testing with a the php built-in server hosted locally.

The results show pretty decent server response times, but on the chrome developer tools the Time to first byte is much higher. Why is this?

Take Note...the screenshots below of the timings are from the SAME REQUEST...CLEARLY

Profiler (www.mysite.com/index.php):

magento-profiler-server-response

Developer tools (www.mysite.com/index.php):

TTFB-chrome-developer-tools

RandomSeed
  • 29,301
  • 6
  • 52
  • 87
tread
  • 10,133
  • 17
  • 95
  • 170
  • 2
    It's anybody's guess here why one is higher than the other. There's no real information to even venture a guess, because we don't know what they are measuring, exactly. – Sherif Sep 22 '16 at 14:54
  • server response time...it is in the question – tread Sep 22 '16 at 15:01
  • Yea, unfortunately "*server response time*" is completely vague, because there's no way of knowing what that entails. **TTFB** measures *Time To First Byte*, i.e. the time it takes the first byte of the response to reach the client from the time the request is sent by the client. However, we have no clue what you're profiler is measuring, exactly. Even if we assume that the profiler time given here and the screenshot from the developer tools were for the same request, we still have no idea how the profiler came up with that time. It might not be including things like time spent in database. – Sherif Sep 22 '16 at 15:07
  • 1
    Put yourself in the other person's shoes that's trying to answer your question. Imagine I asked you "*Why did it take me longer to get to my house than my neighbors house?*" and the only information I give you is that it took me 30 minutes to get my house and 20 minutes to get to my neighbors house. How do you even begin to answer that question with such little information? Surely, you can't do more than make a wild guess. – Sherif Sep 22 '16 at 15:10
  • 2
    My wild guess would be that magento and Chrome DevTools don't measure the same. As far as I understand the Chrome DevTools, they measure the time from start (probably DNS lookup) to finish (when all resources are loaded and the page is rendered). Magento might only profile the execution of certain PHP scripts/modules/whatever – simon Sep 22 '16 at 15:15
  • @simon in chrome dev tools it tells you how long the DNS lookup took and other stuff, in this request the TTFB which is the time it took to receive the first byte from server, which is similar to server response in my book , was much higher than the profiler value – tread Sep 22 '16 at 15:17
  • @Sherif I have updated the question, stating everything so there is no ambiguity – tread Sep 22 '16 at 15:18
  • 2
    @surfer190 I think you missed my point entirely, but OK... Here goes *completely arbitrary wild guess work just for the sake of completely arbitrary wild guess work with not enough information*. Your developer tools response time measurement includes things like network latency. So even if your PHP only takes 589ms to do it's job and the first byte of that response takes the remaining 1,701ms to get to your browser then that's all network latency. Let's see how long we can keep this thread going with wild guesswork, shall we? – Sherif Sep 22 '16 at 15:22
  • @Sherif I'm sorry if I missed your previous point. I have not mentioned that I am testing locally so network latency should not be a `thing`. I will update the question – tread Sep 22 '16 at 17:06
  • 1
    Well, that's great. You just realized that 1 in potentially 1 billion pieces of information are missing. I hope you can see the rhetoric used in my response now and recognize that this question is **far too broad** to answer accurately given that there is not enough information to make any educated guesses about why you got the numbers you got. Remember, we can't see your code. We don't know anything about your system setup. We don't know what your profiler is doing. We don't know what mistakes you may have inadvertently made. ***We literally know nothing***. So don't expect an answer here. – Sherif Sep 22 '16 at 17:12
  • 1
    @Sherif Look mate if you have no clue, just move on to another question. If someone has experienced testing this kind of scenario, they may know the reasons. Just because you don't know the answer, doesn't mean the question is too broad or wrong. It is actually quite narrow... – tread Sep 22 '16 at 18:09
  • @surfer190 You seem to be confusing "*don't know the answer*" with "*can't know the answer*". Your problem here isn't a lack of experience. It's a lack of information. Trying answering my question "*Why does it take me longer to get to my house than my neighbor's house?*" It's the same problem. You don't have enough information to know for sure. All you can do is ***guess***. Good luck with that! – Sherif Sep 22 '16 at 18:23
  • 1
    @Sherif You are missing the mark spectacularly on this one. You can rule out time Queueing, Stalled, DNS Lookup, Initial connection, Request/Response, Request sent and Content Download time. I am asking the makeup of **Waiting (TTFB)** excluding the time spent in the profiler. Maybe open up chrome dev tools before pontificating here. – tread Sep 26 '16 at 14:48
  • @surfer190 It was indeed impossible to answer your question as it was initially phrased. I think the way I rephrased it makes it a bit more constructive, but feel free to rollback my change. – RandomSeed Sep 28 '16 at 10:55
  • Still, litterally anything may cause this delay. Perhaps the Magento profiler did not catch the entire process (imagine a poorly inspired dev messed with Magento internals), or perhaps your web server is just busy. Or your machine is out of memory. Or your power supply may be defective. You need to investigate lower level issues, and this is quite difficult to do this remotely. – RandomSeed Sep 28 '16 at 11:01
  • There are certain things you can do to isolate it though. For example log the microtime a request is received by webserver. then log the microtime at the start of profiling. Then we will see the delay between reception of request. – tread Sep 28 '16 at 12:51
  • @Sherif found the answer, it required a bit of work but I was willing. Rather don't comment when you enjoy pontificating rather than solving problems. – tread Oct 21 '16 at 07:57

2 Answers2

0

Edit

I had written a bit bigger answer but then I realized that you are using the built-in PHP server. Honestly, you should give a real webserver a go. You might be chasing a problem that does not exist (although one can argue that there is something going on because it's not a normal situation - you might be encountering a PHP bug) ;)

Ricardo Velhote
  • 4,630
  • 1
  • 24
  • 30
  • Hmmm please include your bigger answer. Maybe the `router.php` is slowing it down. – tread Oct 03 '16 at 07:26
  • It was related to Apache so it's not applicable. You can read it in the revisions page (http://stackoverflow.com/posts/39814076/revisions). Yep, you should also benchmark `router.php`. If you could also post it in your question it would be helpful as well. – Ricardo Velhote Oct 03 '16 at 07:40
0

Found the issue.

The profiler is not recording included libraries. In the magento/lib folder nothing is recorded even if you explicitly set it to profile.

It seems that we need to use an all-encompassing php profiler

tread
  • 10,133
  • 17
  • 95
  • 170