Solr
  1. Solr
  2. SOLR-3330

Show changes in plugin statistics across multiple requests

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: web gui
    • Labels:
      None

      Description

      When debugging configuration and performance, I often:
      1. Look at stats values
      2. run some queries
      3. See how the stats values changed

      This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes.

      It would be great if the 'plugins' page had a button that would make this easier

      1. SOLR-3330.patch
        6 kB
        Stefan Matheis (steffkes)
      2. SOLR-3330.patch
        6 kB
        Stefan Matheis (steffkes)
      3. SOLR-3330-pluggins-diff.patch
        11 kB
        Ryan McKinley
      4. SOLR-3330-pluggins-diff.patch
        8 kB
        Ryan McKinley
      5. SOLR-3330-plugins.png
        82 kB
        Stefan Matheis (steffkes)
      6. SOLR-3330-record-changes-ui.patch
        36 kB
        Stefan Matheis (steffkes)
      7. SOLR-3330-record-changes-ui.patch
        20 kB
        Ryan McKinley
      8. SOLR-3330-ui-update.patch
        2 kB
        Stefan Matheis (steffkes)

        Issue Links

          Activity

          Hide
          Ryan McKinley added a comment -

          This is a quick sketch showing how we can use the SolrInfoMBeanHandler to output a speciall 'diff' format that will load (without changes!) in the current UI.

          Essentially the workflow is:
          1. The UI takes a snapshot of a plugins response (needs to be XML string)
          2. At some point in the future, you send a post to /admin/plugins?diff=true&stream.body=XML
          3. The handler returns a modified response that only includes changed MBeans and makes the differences clear.

          For example, the stats response after one request will look like this:

          <lst name="stats">
          <long name="handlerStart">1333695069323</long>
          <str name="requests">Was: 2, Now: 3, Delta: 1</str>
          <long name="errors">0</long>
          <long name="timeouts">0</long>
          <str name="totalTime">Was: 3, Now: 4, Delta: 1</str>
          <str name="avgTimePerRequest">Was: 1.5, Now: 1.3333334, Delta: -0.167</str>
          </lst>
          
          Show
          Ryan McKinley added a comment - This is a quick sketch showing how we can use the SolrInfoMBeanHandler to output a speciall 'diff' format that will load (without changes!) in the current UI. Essentially the workflow is: 1. The UI takes a snapshot of a plugins response (needs to be XML string) 2. At some point in the future, you send a post to /admin/plugins?diff=true&stream.body=XML 3. The handler returns a modified response that only includes changed MBeans and makes the differences clear. For example, the stats response after one request will look like this: <lst name= "stats" > <long name= "handlerStart" > 1333695069323 </long> <str name= "requests" > Was: 2, Now: 3, Delta: 1 </str> <long name= "errors" > 0 </long> <long name= "timeouts" > 0 </long> <str name= "totalTime" > Was: 3, Now: 4, Delta: 1 </str> <str name= "avgTimePerRequest" > Was: 1.5, Now: 1.3333334, Delta: -0.167 </str> </lst>
          Hide
          Ryan McKinley added a comment -

          Added a test to show the statistics change across multiple requests.

          I will commit this soon, and we can continue work on the UI side of things

          Show
          Ryan McKinley added a comment - Added a test to show the statistics change across multiple requests. I will commit this soon, and we can continue work on the UI side of things
          Hide
          Ryan McKinley added a comment -

          Here is a first crack at calling this through the UI. It uses blockUI to pause while you run other queris, then will update the UI when you click OK.

          I have it making all the right calls, but can not figure out how to reload the page with the new response.

          Stefan, can you take a look?

          thanks!

          Show
          Ryan McKinley added a comment - Here is a first crack at calling this through the UI. It uses blockUI to pause while you run other queris, then will update the UI when you click OK. I have it making all the right calls, but can not figure out how to reload the page with the new response. Stefan, can you take a look? thanks!
          Hide
          Stefan Matheis (steffkes) added a comment -

          Ryan, the Handler normally returns data structured like this:

          solr-mbeans: [
          	"QUERYHANDLER"
          	{
          		"/admin/mbeans":
          		{
          			class: "org.apache.solr.handler.admin.SolrInfoMBeanHandler",
          			version: "4.0.0.2012.04.07.21.36.12"
          		}
          	}
          ]

          but the diff-response looks like this:

          solr-mbeans: [
          	"QUERYHANDLER"
          	[
          		"/admin/mbeans",
          		[
          			"class"
          			"org.apache.solr.handler.admin.SolrInfoMBeanHandler"
          			"version"
          			"4.0.0.2012.04.07.21.36.12"
          		]
          	]
          ]

          if we could change this latter one and use the same format that we have on the first request, would be easy to merge and show the differences on the page? In the meantime i'll cleanup the js-code a little bit and integrate highlights of changed informations

          Show
          Stefan Matheis (steffkes) added a comment - Ryan, the Handler normally returns data structured like this: solr-mbeans: [ "QUERYHANDLER" { "/admin/mbeans" : { class: "org.apache.solr.handler.admin.SolrInfoMBeanHandler" , version: "4.0.0.2012.04.07.21.36.12" } } ] but the diff-response looks like this: solr-mbeans: [ "QUERYHANDLER" [ "/admin/mbeans" , [ "class" "org.apache.solr.handler.admin.SolrInfoMBeanHandler" "version" "4.0.0.2012.04.07.21.36.12" ] ] ] if we could change this latter one and use the same format that we have on the first request, would be easy to merge and show the differences on the page? In the meantime i'll cleanup the js-code a little bit and integrate highlights of changed informations
          Hide
          Ryan McKinley added a comment -

          Changed NamedList to SimpleOrderedMap in revision 1311292

          It should now look the same in JSON

          Show
          Ryan McKinley added a comment - Changed NamedList to SimpleOrderedMap in revision 1311292 It should now look the same in JSON
          Hide
          Stefan Matheis (steffkes) added a comment -

          Ryan, have a look .. what about this one?

          Show
          Stefan Matheis (steffkes) added a comment - Ryan, have a look .. what about this one?
          Hide
          Ryan McKinley added a comment -

          sweet! Thanks Stefan. I commited this in r1324839

          I think it makes sense to only show the changed elements. The values in the non-changed elements reflect the values when you first visited the page, not when you click "Watch Changes"

          I see two ways to resolve this:
          a. remove them from the UI
          b. change the diff handler so it returns all the values, not just the changed ones. It would add a marker for things that have changed

          I think it makes sense to add in a 'reload' button that will refresh all the stats

          Show
          Ryan McKinley added a comment - sweet! Thanks Stefan. I commited this in r1324839 I think it makes sense to only show the changed elements. The values in the non-changed elements reflect the values when you first visited the page, not when you click "Watch Changes" I see two ways to resolve this: a. remove them from the UI b. change the diff handler so it returns all the values, not just the changed ones. It would add a marker for things that have changed I think it makes sense to add in a 'reload' button that will refresh all the stats
          Hide
          Stefan Matheis (steffkes) added a comment -

          I added the Images in r1324857.

          I see two ways to resolve this:
          a. remove them from the UI
          b. change the diff handler so it returns all the values, not just the changed ones. It would add a marker for things that have changed

          Perhaps i don't get it .. but (b) is what we already have? The diff-handler returns only the changed items, but i'm merging them into the Data we already have from the first request. The Navigation on the left gets an (1)ish-Counter for changed Items, and the List on the right gets an "new" icon for changed Items.

          One Thing regarding (a), i'm not sure if that would be a good one. Image you've selected "CORE" and you're watching changes .. and the only change happens in "QUERYHANDLER" (because at least, the mbean-handler will change) then you're current view will change automatically ;/ if possible i'd like to avoid this

          The "Reload" Link which is already in there has no functionally right know, but i guess it's the easiest way to initiate an typical browser-reload to get the typical view back.

          Show
          Stefan Matheis (steffkes) added a comment - I added the Images in r1324857. I see two ways to resolve this: a. remove them from the UI b. change the diff handler so it returns all the values, not just the changed ones. It would add a marker for things that have changed Perhaps i don't get it .. but (b) is what we already have? The diff-handler returns only the changed items, but i'm merging them into the Data we already have from the first request. The Navigation on the left gets an (1)ish-Counter for changed Items, and the List on the right gets an "new" icon for changed Items. One Thing regarding (a), i'm not sure if that would be a good one. Image you've selected "CORE" and you're watching changes .. and the only change happens in "QUERYHANDLER" (because at least, the mbean-handler will change) then you're current view will change automatically ;/ if possible i'd like to avoid this The "Reload" Link which is already in there has no functionally right know, but i guess it's the easiest way to initiate an typical browser-reload to get the typical view back.
          Hide
          Stefan Matheis (steffkes) added a comment -

          That is what it should look like after getting changes on the mbean-handler

          Show
          Stefan Matheis (steffkes) added a comment - That is what it should look like after getting changes on the mbean-handler
          Hide
          Ryan McKinley added a comment -

          but (b) is what we already have?

          No, right now it only returns the changed items. There are three points in time:
          1. When the page first loads
          2. When you click 'Watch Changes'
          3. When you click 'Show Changes'

          Right now the UI shows the values from 1, then updates the changes between 2&3 – the problem is that the values that may have changed between 1&2 are not reflected in the UI. (Not a huge deal, but not accurate)

          I think the highlight you already added looks good – the "New" icon is a bit misleading because it implies that it is a new value (not just a changed one)

          Show
          Ryan McKinley added a comment - but (b) is what we already have? No, right now it only returns the changed items. There are three points in time: 1. When the page first loads 2. When you click 'Watch Changes' 3. When you click 'Show Changes' Right now the UI shows the values from 1, then updates the changes between 2&3 – the problem is that the values that may have changed between 1&2 are not reflected in the UI. (Not a huge deal, but not accurate) I think the highlight you already added looks good – the "New" icon is a bit misleading because it implies that it is a new value (not just a changed one)
          Hide
          Stefan Matheis (steffkes) added a comment -

          Right now the UI shows the values from 1, then updates the changes between 2&3 – the problem is that the values that may have changed between 1&2 are not reflected in the UI. (Not a huge deal, but not accurate)

          Ah yes, you're right. Hm, will think about that. perhaps there is a quick solution for that. Also for the 'new' icon .. yes, the icon set does not have an 'update' icon ;o

          Show
          Stefan Matheis (steffkes) added a comment - Right now the UI shows the values from 1, then updates the changes between 2&3 – the problem is that the values that may have changed between 1&2 are not reflected in the UI. (Not a huge deal, but not accurate) Ah yes, you're right. Hm, will think about that. perhaps there is a quick solution for that. Also for the 'new' icon .. yes, the icon set does not have an 'update' icon ;o
          Hide
          Hoss Man added a comment -

          can we change this to use an HTTP POST body instead of stream.body request param? ... it's sending some really long ass request URLs that might not work if a servlet container is configured to limit the URL length.

          Show
          Hoss Man added a comment - can we change this to use an HTTP POST body instead of stream.body request param? ... it's sending some really long ass request URLs that might not work if a servlet container is configured to limit the URL length.
          Hide
          Ryan McKinley added a comment -

          It is already using POST with stream.body as a application/x-www-form-urlencoded param

          Are you seeing the long URL in the logs, or in your browser?

          Show
          Ryan McKinley added a comment - It is already using POST with stream.body as a application/x-www-form-urlencoded param Are you seeing the long URL in the logs, or in your browser?
          Hide
          Hoss Man added a comment -

          Sorry .. i was looking at the solr logging (SolrCore.execute) ... because it's using "Content-Type: application/x-www-form-urlencoded" and the stream.body param, it's all being included in the list of SolrParams that get logged.

          So my concern about extra long URLs breaking is a non-issue, but it's still kind of noisy as far as solr logging goes.

          If it was changed to use "Content-Type: application/xml" and send the xml directly then it wouldn't be counted as a solr param, but the handler would still get it as a ContentStream.

          as for how it looks: in my initial impression i didn't realize that it was recording values core all the categories of plugins (ie: i was looking at "Query Handlers" and didn't notice the little grey numbers indicating that "Caches" also had some changes) ... the #BBA500 color used to make the plugin names with changes standout is great (even if you remove the "new" icon completely) so maybe just using that same color on the category names (or at least the little numbers indicating that items in that category have changed) would be helpful to draw attention to them?

          Show
          Hoss Man added a comment - Sorry .. i was looking at the solr logging (SolrCore.execute) ... because it's using "Content-Type: application/x-www-form-urlencoded" and the stream.body param, it's all being included in the list of SolrParams that get logged. So my concern about extra long URLs breaking is a non-issue, but it's still kind of noisy as far as solr logging goes. If it was changed to use "Content-Type: application/xml" and send the xml directly then it wouldn't be counted as a solr param, but the handler would still get it as a ContentStream. — as for how it looks: in my initial impression i didn't realize that it was recording values core all the categories of plugins (ie: i was looking at "Query Handlers" and didn't notice the little grey numbers indicating that "Caches" also had some changes) ... the #BBA500 color used to make the plugin names with changes standout is great (even if you remove the "new" icon completely) so maybe just using that same color on the category names (or at least the little numbers indicating that items in that category have changed) would be helpful to draw attention to them?
          Hide
          Stefan Matheis (steffkes) added a comment -

          Hoss, like this? Visible enough?

          Show
          Stefan Matheis (steffkes) added a comment - Hoss, like this? Visible enough?
          Hide
          Stefan Matheis (steffkes) added a comment -

          Right now the UI shows the values from 1, then updates the changes between 2&3 – the problem is that the values that may have changed between 1&2 are not reflected in the UI. (Not a huge deal, but not accurate)

          Attached Patch would fix this, i changed the workflow a bit - fetching the 'reference xml' is now done right after loading the initial page.

          After a bit playing around with it, i'm not sure, if this is what the user would expect? image the following: Users loads the page, requests /admin/ping or something like this, afterwards hit's the "watching changes" button and stop's this action. he'll see at least two changes .. one on the ping-handler, and one on the mbeans-handler. i would expect, that recording changes just begin's when i hit the button?

          Perhaps it's just a UI-Thing .. maybe we show use some 'loading'-Icon for "Watch Changes" instead of the Eye-Icon, to illustrate that we already watch for changes?

          Show
          Stefan Matheis (steffkes) added a comment - Right now the UI shows the values from 1, then updates the changes between 2&3 – the problem is that the values that may have changed between 1&2 are not reflected in the UI. (Not a huge deal, but not accurate) Attached Patch would fix this, i changed the workflow a bit - fetching the 'reference xml' is now done right after loading the initial page. After a bit playing around with it, i'm not sure, if this is what the user would expect? image the following: Users loads the page, requests /admin/ping or something like this, afterwards hit's the "watching changes" button and stop's this action. he'll see at least two changes .. one on the ping-handler, and one on the mbeans-handler. i would expect, that recording changes just begin's when i hit the button? Perhaps it's just a UI-Thing .. maybe we show use some 'loading'-Icon for "Watch Changes" instead of the Eye-Icon, to illustrate that we already watch for changes?
          Hide
          Ryan McKinley added a comment -

          fetching the 'reference xml' is now done right after loading the initial page.

          eeep. I would expect the changes to be based on when I click the button.

          I think the way to solve our issue is for the diff request to return the things that did not change as well. I'll make a patch for that and see if we can make that work

          Show
          Ryan McKinley added a comment - fetching the 'reference xml' is now done right after loading the initial page. eeep. I would expect the changes to be based on when I click the button. I think the way to solve our issue is for the diff request to return the things that did not change as well. I'll make a patch for that and see if we can make that work
          Hide
          Ryan McKinley added a comment -

          In r1327775 I added an option to get back all the ref elements as well. Add "all=true" as a param, and you will get everything back. It now appends a field to the changed items: "changed": true

          The thought is you can update everything, but only highlight the elements that have changed

          stefan, go ahead and commit the style changes to make the highlight more prominent

          Show
          Ryan McKinley added a comment - In r1327775 I added an option to get back all the ref elements as well. Add "all=true" as a param, and you will get everything back. It now appends a field to the changed items: " changed ": true The thought is you can update everything, but only highlight the elements that have changed stefan, go ahead and commit the style changes to make the highlight more prominent
          Hide
          Stefan Matheis (steffkes) added a comment -

          Style-Changes committed in r1327854 - will check your updates and see how we could integrate them

          Show
          Stefan Matheis (steffkes) added a comment - Style-Changes committed in r1327854 - will check your updates and see how we could integrate them
          Hide
          Stefan Matheis (steffkes) added a comment -

          Updated Patch, using the all=true Param for MBeans-Handler

          eeep. I would expect the changes to be based on when I click the button.

          yepp, right. changed this back to what we had before.

          Show
          Stefan Matheis (steffkes) added a comment - Updated Patch, using the all=true Param for MBeans-Handler eeep. I would expect the changes to be based on when I click the button. yepp, right. changed this back to what we had before.
          Hide
          Ryan McKinley added a comment -

          added in #1329005

          Thanks Stefan!

          Show
          Ryan McKinley added a comment - added in #1329005 Thanks Stefan!

            People

            • Assignee:
              Stefan Matheis (steffkes)
              Reporter:
              Ryan McKinley
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development