Details

    • Type: Story
    • Status: Done
    • Priority: Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 0.9.9
    • Component/s: None
    • Labels:
    • Sprint:
      DEV 2015-10-16
    • Story Points:
      5

      Description

      The current connection usage statistics are viewable on a per-connection basis only, and require that you go to the connection in question within the admin UI to see the logs.

      It would be far more useful if these usage statistics were somehow centralized and filterable, like the current active session interface. Perhaps the active sessions and connection history interfaces could even be unified.

        Attachments

          Issue Links

            Expenses

              Activity

              Hide
              mike.jumper Michael Jumper added a comment -

              Unless this miraculously turns out to be incredibly simple, I think we should aim to not include this in 0.9.8 (plan for 0.9.9 instead), since it would potentially destabilize the release. Too much going on there.

              Show
              mike.jumper Michael Jumper added a comment - Unless this miraculously turns out to be incredibly simple, I think we should aim to not include this in 0.9.8 (plan for 0.9.9 instead), since it would potentially destabilize the release. Too much going on there.
              Hide
              mike.jumper Michael Jumper added a comment -

              The major hurdle with unifying the statistics with the "active sessions" UI is the size of the data itself. We can rely on the number of active sessions being reasonable, at least from the perspective of the client-side filtering in Angular. Even if there are a beastly 10,000 or 100,000 active sessions, JavaScript is perfectly capable of filtering this, and it will not grow with respect to time.

              Historical data, on the other hand, grows over time by definition. Simply limiting the results to the most recent N records will not suffice for heavy loads or large numbers of users. Somehow, the server needs to filter and sort the data prior to returning it via a REST call. The filtering and sorting parameters must function identically to the filtering and sorting of the active sessions.

              For this to work at all, historical data must be removed from the Connection object, and brought to the top level. History records must be queryable in bulk, and in one operation, without having to find their associated connections first.

              Show
              mike.jumper Michael Jumper added a comment - The major hurdle with unifying the statistics with the "active sessions" UI is the size of the data itself. We can rely on the number of active sessions being reasonable, at least from the perspective of the client-side filtering in Angular. Even if there are a beastly 10,000 or 100,000 active sessions, JavaScript is perfectly capable of filtering this, and it will not grow with respect to time. Historical data, on the other hand, grows over time by definition. Simply limiting the results to the most recent N records will not suffice for heavy loads or large numbers of users. Somehow, the server needs to filter and sort the data prior to returning it via a REST call. The filtering and sorting parameters must function identically to the filtering and sorting of the active sessions. For this to work at all, historical data must be removed from the Connection object, and brought to the top level. History records must be queryable in bulk, and in one operation, without having to find their associated connections first.
              Hide
              mike.jumper Michael Jumper added a comment - - edited

              If filtering is done on the server side (which seems to be required), we cannot use LIKE directly on the history table for performance reasons. We will need to:

              1. Accept the reality of a table scan through the guacamole_user and guacamole_connection tables, and join on those when necessary. Using LIKE here is OK, as it will not involve a table scan on the huge history table.
              2. For filtering by date, we will have to recognize numeric and date-like strings in the filter pattern, and generate the necessary less than / greater than / etc. comparisons which can be efficiently performed on the if-they-aren't-indexed-they-sure-will-be-after-this date columns of the history table.
              Show
              mike.jumper Michael Jumper added a comment - - edited If filtering is done on the server side (which seems to be required), we cannot use LIKE directly on the history table for performance reasons. We will need to: Accept the reality of a table scan through the guacamole_user and guacamole_connection tables, and join on those when necessary. Using LIKE here is OK, as it will not involve a table scan on the huge history table. For filtering by date, we will have to recognize numeric and date-like strings in the filter pattern, and generate the necessary less than / greater than / etc. comparisons which can be efficiently performed on the if-they-aren't-indexed-they-sure-will-be-after-this date columns of the history table.
              Hide
              mike.jumper Michael Jumper added a comment -

              REST service changes are now done (both Java and JavaScript) as well as the changes to guacamole-ext: https://github.com/glyptodon/guacamole-client/compare/glyptodon:250ad62...glyptodon:3c5f72b

              Still need to:

              1. Implement ConnectionRecordSet for MySQL and PostgreSQL (currently stubbed out with SimpleConnectionRecordSet, which is simply empty).
              2. Add the "History" tab to the settings interface.

              We should be able to safely get rid of the old mechanism for pulling connection history, if desired. It serves virtually no purpose any longer.

              The ConnectionRecord class can also safely be refactored to be specific to historical data. There is no longer any need for an isActive() - the active connection directory takes care of that, and more efficiently.

              Show
              mike.jumper Michael Jumper added a comment - REST service changes are now done (both Java and JavaScript) as well as the changes to guacamole-ext: https://github.com/glyptodon/guacamole-client/compare/glyptodon:250ad62...glyptodon:3c5f72b Still need to: Implement ConnectionRecordSet for MySQL and PostgreSQL (currently stubbed out with SimpleConnectionRecordSet , which is simply empty). Add the "History" tab to the settings interface. We should be able to safely get rid of the old mechanism for pulling connection history, if desired. It serves virtually no purpose any longer. The ConnectionRecord class can also safely be refactored to be specific to historical data. There is no longer any need for an isActive() - the active connection directory takes care of that, and more efficiently.
              Hide
              mike.jumper Michael Jumper added a comment -

              Currently working great and on master. Still remaining before this is complete:

              1. Limit maximum input size for historical data, so that the queries don't get slower and slower over time ... without bound.
              2. Add appropriate indexes to the schema for columns which now need them.
              Show
              mike.jumper Michael Jumper added a comment - Currently working great and on master. Still remaining before this is complete: Limit maximum input size for historical data, so that the queries don't get slower and slower over time ... without bound. Add appropriate indexes to the schema for columns which now need them.

                People

                • Assignee:
                  mike.jumper Michael Jumper
                  Reporter:
                  mike.jumper Michael Jumper
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: