0

I am using XDebug to profile a large MVC application and it would be much easier to profile individual requests by their URI rather than filename (.php) as several requests are made via internal functions, resulting in multiple grind files for a single page refresh.

I have seen %p = process ID, %t = Timestamp and %s = Script name ( var_path_to_example.php )

It would be much easier if the file could be named more like grind.{domain}{path}.%p

Is this possible? I havent been able to find any other string formatting replacers that may do what im after.

Single page refresh currently creates four grind files ( three for index, one is main request, other two are media compressors ) and one for img.php which is a media path rewriter and resizer.

All of this combined into a single www.example.com/path/to/controller.grind would be preferable for this situation.

Ben Duffin
  • 1,066
  • 10
  • 16
  • Of course www.example.com-path-to-controller.grind.%p would make more sense for the filename lol! – Ben Duffin Apr 25 '15 at 23:18
  • @LazyOne - Apologies for the IDE tag - I have since found out that I cant even view the grind files with PHPStorm 8 - it rejects them and says incorrect parameters! Used Brew to instal qcachegrind which works but I still have four files created for a single page request and would like them combined - I see how the tag was inappropriate, will add correct software name! – Ben Duffin Apr 26 '15 at 21:48
  • While you're fooling around with that, take a break and give [*this*](http://stackoverflow.com/a/378024/23771) a try. Especially if you've got a large project, you can see what it's doing that accounts for a large fraction of time. Profilers tend to have a built-in assumption that time spent by particular routines is what you need to know, and that's a pretty narrow perspective. – Mike Dunlavey Apr 27 '15 at 13:26
  • That seems quite a fun way of doing things - I'll give it a try tonight! @MikeDunlavey If it works pop it in as an answer and I will accept :) – Ben Duffin Apr 27 '15 at 13:31
  • Just as an example, we (my team) are working on a mega-line C# app, and it has a new data-management section. I discovered the other day it had a bad issue - hours to do something that should have taken seconds. I just grabbed three stack samples, all identical and about 10 levels deep. That should be enough to identify the problem and fix it. – Mike Dunlavey Apr 27 '15 at 13:38
  • @MikeDunlavey - although I managed to solve my issue I am still interested in your suggestion - but I think I already have this capability with PHPStorm. Did you mean adding break points to the code and inspecting at execution time? Or have I missed what that other post was about? – Ben Duffin Apr 30 '15 at 08:59
  • I just looked up PHPStorm and it looks like a pretty good IDE. Does it contain a "pause" button? I couldn't tell. When I try to explain this method, for some reason people seem to think I mean adding break points to the code, and when they say that won't work, they are right. You need to break into the running code *at an unpredictable time*, just like a sampling profiler would. Then, the difference is, you can see in detail what it is doing, not just caching a little data for timing. A further difference is, profilers have the ... – Mike Dunlavey Apr 30 '15 at 12:41
  • ... baseless assumption that a lot of samples are necessary. It's not so. It is so if you're after measurements, but you're not. You're trying to ***find*** how to speed up the program, not *measure* it. If you see something that could be speeded up on as few as **two** samples, you've found it, and the fewer samples it takes to get to that point, the bigger the speedup is. Just consider an infinite loop - how would you find it? *Every time* you pause it, you know it's in the loop, so all you have to do is figure out why. Same idea for all performance issues - samples are drawn to them. – Mike Dunlavey Apr 30 '15 at 12:48
  • ... Not to belabor, but I often see this on SO - people find one speedup, by whatever method, so they cheer and go home. Hurray! But what about the next one? It may not have been much at the beginning, but after you clean out the first problem, now the second one is no longer so small. Then what about the third? What I try to point out is the code may well contain multiple problems. If you fix them all, you get *massive* speedup, but fail to find any one of them, and you get far less. And that's the thing about profilers - if there's a speedup they don't find, you're blissfully unaware. – Mike Dunlavey Apr 30 '15 at 13:09
  • 1
    For whats its worth though, in my experience with working through profile outputs ( via KCacheGrind ) I have found and resolved multiple bottlenecks and reduced the apps load time down to 0.02 seconds. But as you said - it took several weeks of careful profiling to find every bottleneck I could and no doubt I missed many others. But even working through what I could find in the profiles helped massively with the load times - its a very good way to review your app, but I agree that you must be meticulous with your reviewing to make sure you find as much as possible ... – Ben Duffin Apr 30 '15 at 13:13
  • 1
    ... which almost always turned out to be inefficient loops, queries inside loops and (to no ones surprise) regular expressions. But I will still try to find a way to "pause the stack" as you put it for a finer grain of control over my inspections. Now all I have to do is find a way to do that in PHP :) – Ben Duffin Apr 30 '15 at 13:15

1 Answers1

0

The answer was to use %R - I found the list of string replacements here Xdebug Settings under the trace_output_name section. It seems that the same replacers can be used for the profiler output names as well.

Name your files like this in the php.ini - "cachegrind.out.%R" to get the URI into the name with slashes replaced with underscores.

Now my grind files look like cachegrind.out._page_minify_css and cachegrind.out._ ( Which would be the root of the domain - exactly what I was looking for in order to tie profiles to requests )

The Short list is this

%c = crc32 of CWD

%p = PID

%r = Random Number

%s = Script Name ( only for profile output )

%t = Timestamp ( seconds )

%u = Timestamp ( microseconds )

%H = Hostname

%R = Request URI ( the one I was after )

%U = Unique ID /9 only since 2.2 )

%S = Session ID

Ben Duffin
  • 1,066
  • 10
  • 16