I just downloaded XHProf from the PECL site, v 0.9.2:
http://pecl.php.net/package/xhprof

Did all the settings in Devel, no problem. Ran a drush command, the output file was created by devel, file name format was:

[run-id].[drupal-page-title]

So went back to where I'd set up xhprof_html to run from (note, couldn't actually find any links to the page direct, though I saw catch's patch was committed, so not sure why) - http://xhprof/ on my laptop - and threw in the run ID, as per the docs:

http://xhprof/?run=4e7083ffa011b

Failed, Invalid Run Id.

Got xhprof to show me the file it was trying to load, and it was:

[run-id].xhprof

Seems xhprof is inconsistent. When you only provide the 'run' parameter it expects a .xhprof extension on the file, but when you specify the 'run' and 'source' parameters together then it does not.

Is it worth addressing this and also providing a [run-id].xhprof file to avoid confusion, or should we just raise a bug report with the XHProf team and ask them to do one or the other?

As an aside, seems to me node ID would be a safer/easier 'source' value than page title. Just a thought.

CommentFileSizeAuthor
#7 devel_1278858.patch2.81 KBdrewish
#5 devel_1278858_lite.patch2.71 KBdrewish

Comments

drewish’s picture

+1 just ran into this and it was a head scratcher... i'm not sure the xhprof people upstream are very responsive. there's a lot of ignored issues in the pecl queue.

drewish’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev

bumping the version so we can fix and then backport.

drewish’s picture

Okay so spent some time digging through this. The root of my problem was that the web server couldn't write the file and xhprof's XHProfRuns_Default::save_run() returns a run id in spite of errors. I think this could use some documentation.

I also found it annoying/confusing that drush kicks out the link as a notice so you don't see it unless you're in verbose or debug mode.

greg.harvey’s picture

Oh, I had the permissions thing too, *before* I got to this. All in all, getting XHProf going was pretty painful. ;-)

drewish’s picture

Status: Active » Needs review
StatusFileSize
new2.71 KB

Here's the simpler version of this. I had a more heavy handed one. I'm sure Moshe won't like the drupal_mkdir() but I dropped a call to t() it should be a fair trade ;)

Status: Needs review » Needs work

The last submitted patch, devel_1278858_lite.patch, failed testing.

drewish’s picture

Status: Needs work » Needs review
StatusFileSize
new2.81 KB

Okay here's one with no drupal_mkdir() and urlencoding of the site name.

Status: Needs review » Needs work

The last submitted patch, devel_1278858.patch, failed testing.

moshe weitzman’s picture

Status: Needs work » Closed (won't fix)

The recommended way to integrate xhprof now is with xhprof module. Once msonnabaum has an RC out, I will remove xhprof integration from devel. His module will build out better UI and integration than devel can.

fp’s picture

Worth mentioning - this seems the top thread search engines return for "Drupal Invalid Run Id": I had to manually create and give the proper permissions to the _xhprof.output_dir_.

Otherwise, the error mentioned above it the one you will get.

geerlingguy’s picture

Same as #10 here (and came in through a Google search): I had to give the 'runs' directory I created to store XHProf runs the proper permissions for allowing write access, and the runs were stored correctly and able to be accessed.

alxp’s picture

Also came from Google. I had a more obscure problem, where one of my Drupal vhosts on the server worked and one didn't. It turns out that the site that didn't work has an ampersand in the site's title, which wasn't getting URL encoded properly when devel forms the URL to get the xhprof output.

Editing the URL and replacing the & with '%26' solved it, but it looks like I should just ditch this functionality and use the other module.

prdctvtxt’s picture

Issue summary: View changes

Same as #10 had to give permissions to the run directory, in my case it was /var/tmp/xhprof