Cognos Planning Thick-Client (Analyst, Manager, CAC) across WAN (diff domains)

[jeffowentn]

Ok, I have an issue with performance for some of my users.  This is pretty much isolated to the Cognos Planning 8.4.1 Thick-Client modules (Analyst, Manager, and Analyst Add-In for Excel - these particular users are not currently using the CAC, although I hope to bring them around that at some point).  They are on a different domain, in a different city.  There is an MPLS connection between us and them, and they have a 45 Mb pipe.  Pinging is roughly 26 ms between us.  We are looking at doing some testing with Wireshark, but that's not my area of expertise.

The users are seeing something like:

1.  Refreshing a screen in manager takes me roughly 30 seconds and them roughly 30 minutes (not a typo)
2.  Logging into Analyst takes them 1-2 minutes, whereas I get in probably in less than 5 seconds
3.  Opening a large d-cube (admittedly, this is large) takes me about 3 seconds and it takes them 1 min 6 seconds (simply pasting the h2d d-cube data file in Windows Explorer only takes them 26 seconds)
4.  Opening d-links takes 30-50 seconds
5.  Opening Manager takes even longer than the 1-2 minutes (I would have thought that would be roughly the same as Analyst)


So, here's a bit more about our environment, and then some areas of question.

In DEV, all of our servers our Win 2003 SP2 with a SQL 2005/2008 backend.  For PROD, our servers are a mix of Win 2003 SP2 and Win 2008 R2, also with a SQL 2005/2008 backend.  We're using Access Manager/Sun One Directory for authentication, with roughly 10,000 userclasses and around 500+ users, although only about 350-400 users are Planning users (the rest are BI).  All content, servers, databases, etc., exist at my location.  The thick-client is locally installed on the users' machine at the remote site.  We do have Citrix, but the users leverage the Analyst Add-In for Excel heavily.

That being said, here are the ideas I have.  I would appreciate any critical feedback as to my suggestions or any other ideas you might have.

1.  We can move the Analyst objects to a server in their local office since they would be the only ones using that content on a regular basis.  The only other users would be my team for development/troubleshooting purposes.  While I would prefer to have everything in one location, this may be a viable long-term solution as long as their local IT will take ownership of regular backups, security, and restoring if necessary.

2.  Since we have nearly 10,000 userclasses, I was considering creating a second namespace strictly for remote users to authenticate against for the purposes of accessing their thick-client content.  Analyst and CAC are only secured for groups of analysts (for exampe, Corp FP&A would allow all of its Modelers access to all of it's content in Analyst and CAC) and not at any lower level of granularity.  This means we could have a second namespace with roughly 10 userclasses and roughly 25 users, and that's it.  I know you can use multiple namespaces in Cognos Connection, but I have not looked into this for the thick-clients.  Does anyone have any thoughts with this?  What are the ramifications of one namespace for the thick-client content and a separate namespace for accessing Cognos Connection/Contributor web for the same users?

3.  Someone at IBM Cognos suggested giving the users access to the servers directly and allow them to remote in.  While I was shocked at the suggestion and would not consider it at all, we might be able to create some VM's of desktops to allow the users to remote into.  This would need to be tested, and we would also need to make sure there are shares that would allow them to get back to their local files, particularly for the Analyst Add-In for Excel.

4.  I raised the question of OpenDJ to replace our Sun One Directory LDAP on this site, yesterday, but I was wondering if that might improve performance, as well.

We are currently in the midst of the budget cycle, so I'm looking for the biggest bang for our buck, in terms of least effort and greatest impact in the short-term and what we should be doing long-term.

Even if you can't address everything, I would greatly appreciate your feedback or questions on pieces of the puzzle, too.

Thanks, so much!

Jeff

[smiley]

The thick client apps are basicly lan apps. (positioned by ibm/cognos as requiring 100mb each)
Loads of uncompressed and non optimised small tcp/ip packets, that hate latency.

Put them on a terminal server or a vdi, whatever suits best but stop squeezing that traffic through your wan link.

[jeffowentn]

Smiley,

Thank you for the response.  Forgive me, but what is VDI?

Also, I believe there are licensing costs with terminal services.  I'm not sure if this is an option, but would that be any different than simply creating some virtual PC's for the users to remote into?

Any thoughts on the Access Manager question?

Jeff

[smiley]

VDI is Virtual Desktop Interface. The same as the virtual pc's you describe.
Your accman setup should work just fine. Planning can handle multiple namespaces without a problem.

[SomeClown]

1.  We can move the Analyst objects to a server in their local office since they would be the only ones using that content on a regular basis.

I'd suggest conducting a test with one cooperative user.  You'll need to enable non-standard filesys.ini to allow a local copy of filesys so you can have local copies of Analyst libraries.  Performance from local machine would determine if its WAN, local machine resources, or something else

2.  I know you can use multiple namespaces in Cognos Connection, but I have not looked into this for the thick-clients.  Does anyone have any thoughts with this?  What are the ramifications of one namespace for the thick-client content and a separate namespace for accessing Cognos Connection/Contributor web for the same users?

All users (web or thick) would get a prompt to select the desired namespace.  It might break some integration pieces so test out any automated build processes you have.

Also, I don't know if they fixed it, but part of the client dialog (web or thick client) used to pull all userclasses down for a user.  If someone belonged to a lot of userclasses, this could severely impact performance (local resources and web traffic).  That you have 10,000 userclasses for 500 users suggests this might be an area for exploration.  (I'd be wary if someone belonged to more than 10, but that is only a personal opinion).  With that kind of ratio, I'd encourage you to consider creating a userclass for a person, and map that into objects.  Might not be feasible but something to look at.

3.  Someone at IBM Cognos suggested giving the users access to the servers directly and allow them to remote in.  While I was shocked at the suggestion and would not consider it at all, we might be able to create some VM's of desktops to allow the users to remote into.  This would need to be tested, and we would also need to make sure there are shares that would allow them to get back to their local files, particularly for the Analyst Add-In for Excel.

Probably a support person that is unaccustomed to articulating a solution.  For WAN deployments, historically its been a TS server like Smiley suggested.  That may have been what support was trying to say.

4.  I raised the question of OpenDJ to replace our Sun One Directory LDAP on this site, yesterday, but I was wondering if that might improve performance, as well.

Unlikely.  LDAPs are optimized for reads.  I would expect that any differences (+/-) would be incremental at best.

Smiley's suggestion is probably the best option for resolution of the performance issues.

[ykud]

Second (third?) the Remote Desktop to VMs / Citrix solution.

Shouldn't be anything LDAP related, SunOne is really fast enough usually.

Just another point:
" these particular users are not currently using the CAC, although I hope to bring them around that at some point" — what for? I usually try to severely limit user's exposure to CAC, since it's really IT-oriented. You can run CAC macros as jobs in Cognos Connection and this allows to a) use a more user-friendly web page interface b) have a decent audit  and potentially Event Manager on macros/job executions.

[jeffowentn]

Smiley - thank you for the clarification on the VDI

SomeClown - I've already created a test library that resides in their local network without having to mess around with the filesys.ini - I just have the administration for that library pointing to their server instead of ours.  Performance is better, but there is still a lag with task-related performance for some things and especially for authentication (expected).

I was hoping to create a second namespace to cut down the number of userclasses significantly.  We have a lot of old userclasses that stem from some antiquated content the business is just now letting me "archive."  So, I will work on that to some extent.  The greater majority of the user classes stem from managing security during the budget cycle without having to run constant GTP's.  While 8.4 allows granting security to Contributor app's by name from the Cognos namespace, it requires a GTP each time.  By having the user classes, I simply assign the user to the user class that is already granted rights in the app and we are done.  Not the best, but it streamlines the numerous security requests received in the middle of the budget cycle.

ykud - Regarding the comment about moving them to the CAC...it was more meant to suggest that there might be the opportunity to take everything they are doing in Analyst and move it to Contributor.  We just brought them into the fold, so to speak, so I am not aware of everything they are doing - no time to dig into this for the current budget cycle.  I expect I might be able to move them to a contributor app to address performance issues for their usage part of the process.  They will obviously still leverage Analyst to roll-over their content from one budget cycle to the next.

Thank you all for your feedback.  I'll see about testing the add'l namespace as a possible short-term improvement while we work on long-term solutions.  That seems like possibly the biggest bang for our buck without having to worry about add'l servers/licensing, etc. for the VM's, VDI's, TS, etc.

For my networking guys...do any of you have a link that explains the technical issue with trying to use the thick-client software over the WAN?

Jeff