[requests storage] best management practices for high volume request queues?

[AdinaPi1]

Hi Skye! A few years ago, we noticed a huge degradation in performance in reporting on requests (sometimes reports would time out and not load at all), and it turns out it was because we had too many issues on our request queue project. Workfront let us know that they created new projects every quarter (this is when they still used Hub for support request), and we started doing the same thing. Our request queues are all in the same portfolio, but most of our reports are based on request type, or which team the issue is assigned to (or resolve project portfolio id) I just checked, and our original request queue project had 2473 issues and 2352 documents. Adina

[DerekVi]

Interesting, we've been using workfront a little over a year and run our helpdesk through the tool. I'm not sure we're in the high volume category, but I'll share our experience. Our main helpdesk project has just under 5k issues with just under 10k documents (most of these are duplicates from email attachments of avatars). We haven't seen any major system performance issues, but we are also are not running big reports on all of the helpdesk data constantly so maybe we have a slightly different use case. Derek Visch Level Data

[VicAl]

I wonder if Workfront has addressed this in a previous release or something. Because I had heard of limitations such as this a while ago and was preparing to move requests to another project, etc. But we weren't seeing any problems. So I went with the "if ain't broke..." philosophy. That was a couple of years ago. We now have over 40,000 requests (only 300 still open) in our request project and I still haven't seen any issue with reports or anything else. Shoot, I just jinxed us, didn't I?

[Doug_Den_Hoed__AtAppStore]

Hmm; dunno Vic, If a tree falls in a forest but you call it, maybe there'll be no sound -- but according to "https://support.workfront.com/hc/en-us/articles/115003574147-API-Basics">this link , I'd say you just passed the "Trouble in 10,000 records" road sign: Max Number of Objects 50,000 The result set cannot include 50000 primary and secondary objects. Max Number of Fields 1,000,000 When the result set is fewer than 50000 objects, your results may include at most 1,000,000 fields. I've visited Trouble, btw, during my API Harley-touring (on one inauspicious trip, with Narayan in my sidecar): nice place to be From. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[VicAl]

"Big Trouble in Little China" So now you said "resulting set". Is that to say as long as my Report isn't returning 50K records, it's ok that the project has over 50K Issues? Thus, if my report was only looking at Open records, it'd still be fine. Or is it just bad bad things once we reach 50K?

[Doug_Den_Hoed__AtAppStore]

In my experience, "50,000 is a number best avoided." By design, the API can only handle 50,000 records. So -- imagining what's happening behind the green screen -- if you have 60,000 Issues in total and ask for only the 500 Open Issues, although you might get the 500 you expect (as you do today), I would not be surprised if you got 432. (Or 398. Or 493. Or a different 493) depending on which (random) 50,000 of the 60,000 the query happened to retrieve on any given execution. This sounds like a good time for a second opinion -- @Darin Patterson or @Will Schmidt , would either of you kindly educate us further? Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[AdinaPi1]

On a related note, I'd like to know what's the recommended max number of projects in a portfolio. For a while i thought our poor reporting performance could be related, but we haven't done anything about it yet. We have thousands of hour entries and custom data on these projects as well... Adina Pierce Cisco