Hello,
when profiling a magento website, I see that there are multiple profiling results for a single page request in the browser. This is correct because each page does multiple ajax requests to fill different blocks and all of them pass through /index.php

Unfortunately in the profiling results I only see the script name (/index.php) and not the requested uri (that is catched by index.php with a rewrite). Do you know how to identify the request uri of each profiling result?

A bit ot: do you plan for the future to show profiling results in a tree to see a kind of stacktrace like newrelic?

Tnx

My understanding is that the info about original URL, including GET arguments is passed through some variables according to rewrite rule(s). Different site or different shop can do this differently. How would debugger guess where to find the URL?
Perhaps I can provide an API in debugger to set title for profiler results. But a) this would require modification(s) in code and b) won't work without debugger, so you'd have to wrap such calls with if statement that would check whether debugger is loaded.

As of further improvements, yes I have plans inline with that direction.

Hi Dmitri,
My only request was to show the request uri somewhere because each page profiling I start will trigger the profile of the scripts loaded with jquery or iframes too.

Probably I'm not explaining well, should I paste a screenshot?

I understand what you mean. Please try to understand what I mean. Run phpinfo() function instead of your script in index.php and check if you can find original URL with arguments. Debugger can't guess where this URL is.

Isn't $_SERVER['REQUEST_URI']?

debugger can't access this global variable?

REQUEST_URI? it's what you get. /index.php
Where is URL?

REQUEST_URI and script_name are different things.

Eg in many cms all the urls are managed by a router script /index.php

It means all the different urls with different REQUEST_URI are managed by the same script_name index.php

This is true if the script is run in the webserver environment. Not true, of course, if run from cli

But probably you refer to something else.

Hi Dmitri,
I've built this test.

I've created a php script named "test.php" with this content:

<?php
echo $_SERVER['REQUEST_URI']."<br>";
if (!$_GET['num'])
echo '<iframe src="/test2.html"></iframe>';
?>

In the .htaccess I've put:
RewriteRule ^test(.*)\.html$ /test.php?num=$1 [T=application/x-httpd-php,L]

In the browser I've requested /test.html and in output I see:
/test.html
/test2.html (in the iframe)

I've run the profiler for /test.html and I get 2 results (because 2 urls were requested):

1st result (on the bottom):
Summary
Summary
File: C:\Users\pc\Documents\SITI\Shopping\www\html\test.php
Function:
Function time: 0,491 ms
Function time with children: 0,488 ms
Functions total: 0,491 ms
Page total: 3,883 ms

2nd result (above the 1st result):
Summary
File: C:\Users\pc\Documents\SITI\Shopping\www\html\test.php
Function:
Function time: 0,126 ms
Function time with children: 0,124 ms
Functions total: 0,126 ms
Page total: 0,672 ms

As you can notice the 2 urls requested were /test.html and /test2.html, but in the profiler I can only see the 2 script names behind such urls (C:\Users\pc\Documents\SITI\Shopping\www\html\test.php)

And it seems not always true that the order of the profiled pages in PHPED is the same order the pages were requested in the browser (sometimes the parent page is the second or the third, perhaps depends on the calculations made client side).

I hope this test case makes more clear what I'm asking. It would be great if the profiler on the server would be able to access some global PHP variables and send them to the client. In this case it would be great to receive REQUEST_URI and QUERY_STRING.
I don't know how the dbg extension exactly works to gather the data, but maybe can access such variables or add some fixed opcodes at the beginning of the script (when the profiler is active) in order to read them

Side OT Note: you can notice here too that "Function time with children" is < "Function time", while, from your explanation, I understood that "Function time with children" = "Function time" + time spent on children (that cannot be negative)

Thank you for your time spent replying to me.

Yep, looks like a good idea. Thanks, I'll update dbg-9.3 to support URIs. Not sure about the order of requests. I'll check what can be done to preserve it.
RE Function time with children, still waiting for your feedback on how to reproduce. Can you try to experiment with class auto-load and the other php-core related callbacks that magento might use?

thank you - I'm very happy to contribute a bit on this big piece of software perhaps to guarantee the order of requests you can try gathering the microtime(true) at each script start (not sure if possible) and you provide this info back to the client together with the REQUEST_URI.

For function time with children I've spent some amount of time today with Autoload, without being able to reproduce the big differences I shown the first time I'll try again in the coming days.
The problem I mentioned was that the profiler was showing a much bigger time then the time measured with microtime(true).

But can you try to profile my small script in the previous post?



in that one there is a small issue with the timing too:

Function time: 0,126 ms
Function time with children: 0,124 ms

If the "Function time with children" is calculated on client side it seems that should not be possible to be smaller than "Function time". Right?

Hi Dmitri,
were you able to test the profiler with small script above?
I've just installed latest phped (19.2) with lastest dbg (v9.2. with my php 7.2.19 and it continues to give "Function time with children" < "Function time" [last run 0,103 sec Time with childring vs 0,105 Time]

Thank you

Perhaps, you are not accurate here . It sounds like really the timing was 0.103 milliseconds vs 0.105 milliseconds. Difference of 2 microseconds, higher than timer precision, shouldn't worry anybody