Skip to end of banner
Go to start of banner

2011-11-25 Matthias Huber

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Matthias was not tested with the scenario, but more gave several suggestions on the problematic things noticed in the testing

Outcome

Suggestions

  • Define data wizard page
    • Use horizontal layout, user expects that the additional options are in the line with selection. Correlation with reading left to right.
    • Hide the additional options tabs, show only the one that the selection is made for.
    • Do name the additional options tabs by the data that option is selected for, but call them all "Additional options". Selected item should define data type.
  • Year is missing in the selection of the start/end date in the time-frame wizard page.
  • Double click on the storage or CMR, where Data explorer is opened should show the action progress! When trying to open the storage that had a lot of data, UI was not-responding for 3 seconds.
  • When opening aggregated views in the storage, there is OOME on the UI if a lot of data is there to be loaded. This is because first all data is loaded and then aggregation is done. This is not acceptable. Thus, parts of data should be loaded and aggregated, in several iterations. Maybe the definition how much data can be loaded in one iteration is a good protection.
  • With a big load test, with extracting all invocation children, the indexing tree still gets quite big if a lot of data is saved. Approximately indexing tree in this situation takes 10% of the complete data. Thus with, 1GB of data we have a indexing tree of 100MB, that has to be leaded in memory (footprint in the memory will be considerably bigger than on disk).
    • Solution: Some part of the tree can be removed. For example, if we have a leaf that has only Timer data in agent 10, with method ident 20 we don't have now to save descriptor for each data. Cause, for any further filtering of the data we have to de-serialize all data in the leaf! Thus, since the complete leaf is serialized we should only remember the total size of complete leaf (sum of all elements size).
    • Solution was tested already on Friday, bringing 99% of the decrease in indexing tree size!!! Plus, faster reading and writing to the indexing tree, because only size needs to be updated.
    • However, the solution can not be used everywhere. For invocations we need to keep the old style tree, cause loading one invocation has to directly de-serialize only that invocation. Also, there has to be analysis if other types of data (like Exceptions) can be saved in the new style or not.
  • No labels