Magento profiling |
Site Admin
|
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. |
||||||||||||
_________________ The PHP IDE team |
|
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? |
||||||||||||
|
Site Admin
|
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.
|
||||||||||||
_________________ The PHP IDE team |
|
Isn't $_SERVER['REQUEST_URI']?
debugger can't access this global variable? |
||||||||||||
|
Site Admin
|
REQUEST_URI? it's what you get. /index.php
Where is URL? |
||||||||||||
_________________ The PHP IDE team |
|
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. |
||||||||||||
|
Site Admin
|
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? |
||||||||||||
_________________ The PHP IDE team |
|
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 |
||||||||||||
|
Site Admin
|
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
|
||||||||||||
_________________ The PHP IDE team |
Magento profiling |
|
||
Content © NuSphere Corp., PHP IDE team
Powered by phpBB © phpBB Group, Design by phpBBStyles.com | Styles Database.
Powered by
Powered by phpBB © phpBB Group, Design by phpBBStyles.com | Styles Database.
Powered by