As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at firstname.lastname@example.org and provide your corporate email address, company, and name.
We use WebFOCUS in a multi-tenant capacity and currently have about 3,400 homeapp folders on our production environment. We've seen a substantial loos of performance with dynamic auto-prompts and active reports. Our development environment has about 400 homeapp folders and things run far faster.
Two major observations: 1: If I make a user a Server Administrator then reports run extremely quickly compared to any non-Server Administrator user 2: When I do a trace on a non-Server Administrator user, I see that all folders, including homeapp folders, are scanned for each security group the user is in. The Server Administrator basically skips the scan (I assume because they have access to everything, so why calculate effective permission?). The user obviously has no access to anyone else' homeapp folder, but they are still scanned to calculate permission.
As a test, I loaded all homeapp folders from production onto development (now I have around 4,000 homeapp folders plus all regular master file folders). -A fex with 1 auto-prompt form the CAR file went from 1.5 seconds to 8.5 seconds -A 3-record active report went from 5 seconds to 1 minute (yes, for real).
What options do I have to prevent the number of folders on the system from impacting performance like this?
Thank you!This message has been edited. Last edited by: FP Mod Chuck,
Waz, yes, I do have a case opened. The focus has been on why dynamic parameters are so slow on our production environment and only recently have I found it seems to be related to the number of application directories.
I'll keep folks posted here, but I hoped that the community may be able to shed some light on this and best practices to avoid it.
What version (precisely) of the WebFOCUS Reporting Server are you running ? I tried to find this in your case (I assume it is 200211089) but the information is not present and I found some contradictory info : while your signature says 8203m the hottrack case indicate 8205.
I reported for a French Customer a while ago (January 2019 in version v8203m Gen 1349) on the Reporting Server a problem related to "Access Control Rules processing performance". [HOMEAPPS goes into this category since it induces rules to protect access to everyone folders]
Like in your description performance for server administrator would be much better than regular users (because for server admin Access Control are not checked)
Improvments have been made since then and have been included in various Gen of 8203m/8205/8206 around end of March 2019.
So depending on the release you have, this may or may not applied to you.
You can suggest to your IBI support contact to look at 190118093 and related projects
[In any case I'll be very much interested to know the outcome of this]
Posts: 16 | Location: Information Builders France | Registered: May 22, 2003
Thank you for the reply. You're right, I need to update my signature. We are running 8205.10 Gen 1537 from March 17, 2019. So, what you're saying is if we would've taken a build from 2-3 weeks later we wouldn't have these issues?
We have a copy of 8207 in pre-development testing. I haven't put it through the paces on this specific issue yet, but sure will now! Thanks for comments and reference case!
Well, I can't believe my eyes but I've done my best to replicate this at 8207 and the non-Server Admin user runs a report faster than the Server Admin. In other words, the trace file for the non-admin is a tad smaller and the report run a bit faster than the admin.
This is using 8207.13 (gen 1918). We're also using out-of-the-box homeapps with nested_app = y just like on our 8205.10.
While I'm not comfortable marking this case "solved" without some more research, this is certainly encouraging!