How to differentiated between domains?

thebeline commented 9 years ago

I am running this on multiple domains, how do I differentiate between them?

markstory commented 9 years ago

From the profile list you cannot, the only way you can separate domains is by looking at each profile run. Until this feature gets built, it might be best to run separate instances of xhgui. Alternatively, you could take a stab at building the domain filtering :smile:

thebeline commented 9 years ago

An update: This is actually built, it is just not fully integrated/prettyified.

The SERVER global is logged for each run, meaning we have access to really all identifying information for a run, including the Domain, the Hostname, the Host IP, the Remote IP, the Request Type and enough data to indicate SSL, etc.

Filtering to a specific domain is trivial in the Custom View, enter this into the Selection Criteria:

{"meta.SERVER.HTTP_HOST" : "www.domain.com"}

The primary issue here is that I can not access the profile for the returned results.

Also, there is no way to save these custom views, even as a bookmark.

So, that said, I think I will add a couple of commits.

preinheimer commented 9 years ago

On the XHProf UI I handled this by putting some drop downs in the page header for the domain and server. When set they filtered every search based on that criteria.

PRs very much welcome :)

thebeline commented 9 years ago

I have been thinking about this, and I think we need to break the "search" out into its own controller (much like "Custom/Query") and it's own Record method, and update all pages to use ajax to query and build their tables (for Runs).

This will unify the search and filtering capabilities of all pages, and could even allow for custom "Tabs" (saved, maybe in a cookie).

In the JSON response we would include all headers to display, including the Columns "Name", "Type", "Link Base" and "Link Source".

What the client does with this data is up to it, but for our purposes:

The type could trigger some formatting and conversion actions: datetime would triggger a timestamp to date-time string conversion, microsecond would trigger appending 'us', etc.
The link_base would trigger creating an anchor tag to link to a particulair place. The link would be a combination of the link_base and the value (before conversion) of the cell.
The link_source would indicate if the value to build the Link with should come from somewhere else.

Example:

{
    'headers' : {
        'url' : {
            'name' : 'URL',
            'type' : 'string',
            'link_base' : '/url/view?url=',
        },
        'time' : {
            'name' : 'Time',
            'type' : 'datetime',
            'link_base' : '/run/view?id=',
            'link_source' : 'id',
        },
    },
    'data' : [
        {
            'id' : '2499804d22dca100251297c1',
            'url' : '%2Fdirectory%3Fcat_id%26prod_id',
            'time' : 9757658765,
        },
        ...
    ]
}

The idea is you would only display the columns that have corisponding headers (ie, you would not render the id column, because there is no header for it, but it is there for use as a link_source for 'time').

The other option is the system doesn't rend any header information, and just the runs data, and the template takes it from there. I like the first option, as it allows for some semantic information, but either way.

The general idea is to make all Runs Lists behave the same way, using the same methods. This will allow better flexability, and unify the look and feel (right now, the Custom View does not render the Date Times, or give any links).

The cool part, as I mentioned, would be that this would allow custom Tabs fairly easily, as most of the Tabs are currently just variations on sorting (Longest Wall Time, Most CPU, Most Memory). I could easily set up a tab with search params that gives Most CPU on Server X.

With custom Tabs, I would imagine no way to save them, just an option to delete a Custom Tab, or Add New Custom Tab with Current Parameters. Of course, you could change the parameters while looking at the Tab, but they would not be persistent (refrresh and the Tab is reset to it's saved state).

If you like the sound of that, I am going to work on making a certral and reusable query method and return format, then work to make the various tabs use that one location, and one template. Wish me luck.

markstory commented 9 years ago

I like the idea around making the main list page the same underlying code as custom query. Having some simple to use filters, and the advanced query options sounds great.

Building custom tabs is also pretty neat sounding.