TRIRIGA

 View Only

  • 1.  Performance issues when making TRIRIGA Advanced Report available as a Portal Section on Dashboard

    Posted 16 days ago

    We have built an Advanced Report that hits a table containing about 500,000 rows. When we load the report in Advanced Reporting, the query runs, and the report renders in about 15 seconds. We attempted to make this report available as a portal section for a specific security group to add to their native TRIRIGA dashboard (about 30 users). WE encountered two issues: the report would never load as a portal section, and when multiple users from that security group logged in, it caused massive system-wide performance issues to the point that we had to restart servers and delete that portal section to restore our system. Have others found ways to successfully embed Advanced Reports in native TRI portal sections?

    Thanks! 



    ------------------------------
    Robert Binion
    ------------------------------


  • 2.  RE: Performance issues when making TRIRIGA Advanced Report available as a Portal Section on Dashboard

    Posted 13 days ago

    We have the same problem - not with the portal section part, but just with multiple users hitting the same report and then the whole system crashes.  We have had a support ticket open with IBM for 187 days old.  A developer that works for me has identified the problem that Tririga Reporting is not paginating the data but instead pulling all the data back at once (not best practice for development).  He sent over his finding to the Kurve Team with a suggestion for improvement - this was about a year ago now.  We haven't gotten anything back on next steps to resolve the problem.  All they tell us is that we need to make a bunch of targeted and filtered queries to not pull back so much data for it to work for us - to me that is unacceptable.



    ------------------------------
    Megan Geers
    Project Lead
    Lockheed Martin
    Orlando
    -
    ------------------------------

    Original Message


  • 3.  RE: Performance issues when making TRIRIGA Advanced Report available as a Portal Section on Dashboard

    Posted 8 days ago
    Hi Megan, the support ticket you mention here is open and actively being investigated by IBM. We are aligned that safeguards should be in place to prevent the system from experiencing performance outages in the event of overloading the system with requests. If you'd like further updates, reaching out to support on that ticket might help provide more clarity on where things stand. 
     
    We appreciate your idea for pagination, however, paginating the data (i.e. loading chunks of data at a time) would result in losing key features like being able to create a graph, grouping, aggregating, custom columns, and pivot tables. These features rely on the entire data set in order to function. There's a trade-off in performance when initially loading the whole data set (especially if the data set is quite large), but then the user has the full extent of these key features once the data has loaded. 
     
    As we've discussed, TRIRIGA handles features like filters, grouping, and aggregating on the base query itself - it has safeguards in place when it asks TRIRIGA for the dataset.
    For pagination per your request to work with TRIRIGA Reporting, there would need to be extensive changes in TRIRIGA to be able to handle the features currently available in the TRIRIGA Reporting application. 


    ------------------------------
    Ashley Walter
    ------------------------------

    Original Message


  • 4.  RE: Performance issues when making TRIRIGA Advanced Report available as a Portal Section on Dashboard

    Posted 8 days ago
    Hey Robert! Thanks for sharing your experience with the report in your portal section - I imagine that was quite frustrating to deal with. My name is Ashley and I'm from the Kurve team. 
     
    The large size of this particular report being on a page shared by multiple users sends requests to TRIRIGA that TRIRIGA's API ultimately cannot handle - resulting in the system-wide performance issues you encountered. 
     
    There are shared sentiments that safeguards should be in place to prevent the system from experiencing performance issues and we are actively collaborating with IBM to classify and solution on the issue. 
     
    In the meantime, we do have a couple suggestions to alleviate what you're experiencing in the portal section: 
     
    1. Have 'Query Filters' created on the report so that it isn't auto-run for each user when they land on the portal. The user can click "skip" or pre-filter the data which would reduce the resources required while providing a more specific view.
    2. Reduce the underlying TRIRIGA query size so that the request isn't as large, therefore, not requiring as much memory to run. System Filters, like dynamic date ranges, could be helpful in achieving this. 
     
    To speak to your use case in particular, if you find that the need is to pull all 500k records at one time, there are other tools better suited for especially large datasets. The general rule of thumb is that TRIRIGA Reporting can do 80% of your ad hoc, everyday reporting needs. The 20% that falls out of TRIRIGA Reporting scope, like large historical data pulls, should be created with an external BI tool. 
     
    TRIRIGA Reporting was built to handle ad-hoc request sizes based on the available resources from TRIRIGA and each environment's unique setup. 


    ------------------------------
    Ashley Walter
    ------------------------------

    Original Message