Powerbuilder window slow to open in Citrix

[Former Member]

In the last year we have started using Citrix - XenApp for our PowerBuilder applications for offsite employees. It has worked fine until recently when a certain (fairly complex) window being opened from one of our applications began opening very slowly (2 minutes or more to open and load data). That same window is being opened from other targets and from its own target. It always opens fine from its own target, but very slowly from other targets.This also doesn't happen to every user either (although once it starts happening to a user it continues to be an issue for them). We have confirmed it's not a database issue because while it is loading we do not see processes on the database for the user opening the window. I have yet to be able to reproduce it through Citrix on my machine.

This will most likely end up being a issue that needs to be resolved with our Citrix support, but I wanted to know if others have had experience with PowerBuilder apps and Citrix having performance issues such as this. Any thoughts on where to go from here would be much appreciated.

Thanks.

[former_member1333806 · Accepted solution]

Not necessarily a Citrix problem, but in environments when certain operations can be slower (e.g. reading from certain drives), I've seen apps that are looking for resources that aren't bound into the application can slow down considerably. I'd put SysInternal's Process Monitor on the task (filter to your task only, or you'll get overwhelmed with data) and see if it's going off in search of resources. For example, I've often seen apps going off in search of graphics attached to a menu when I open up the window. Also, I've recently stripped out calls from an old framework that were calling a DLL that was no longer distributed with the app (so the app had to go hunting down the system path for that DLL on every window open).

Getting graphics bound to the executable is a little tricky, because what's in the PBR has to match exactly what is in the code, so for example, "C:\MyProject\file.ico" in the PBR won't match "file.ico" in the code. (At one point, I'm not sure if it's still true or not, the match was case sensitive as well.) This challenge is one of the points of the "PBR Plus" report in my tool, PBL Peeper (this link is temporary until I can get my site updated) on the Reports tab. This will build you what it thinks is the PBR you need (I primarily use it to compare against my existing PBR, since it might miss something, and manually evaluate the discrepancies). It also tries to figure out if any graphics are "missing".

PBL Peeper also will create a list of external function declarations (no guarantee that they're all used), on the Lists tab, and it's easily sortable by library so it's pretty easy to look for DLLs you don't recognize.

Of course, barring myself or anyone else taking a shot in the dark and hitting your bulls eye, the ideal thing to do would be to do a performance trace/profile of the application so that you can see which part of the window opening is slowing down. (Since you don't mention which version of PowerBuilder you're using, it may be worth pointing out that this is only available in Enterprise version of the product, back in the days when non-Enterprise versions were available.) Ideally, you could create a version of the application that included your TraceBegin(), etc... statements, maybe even with something that could determine if the trace would run (e.g. hidden menu item, INI or registry setting). One caution is to make sure the calls come out evenly (and I'm not even sure how to describe this well); one thing I've found is that when the trace doesn't have some kind of symmetry with how it's run, the trace reading functions can fail. So, putting TraceBegin() in the script that Open()s the window and the TraceEnd() in the Cancel button on the window can be bad, but putting the TraceEnd() after the Open() is OK.

Good luck,

Terry

[Former Member · Accepted solution]

Thanks for the info. After being able to reproduce it with a login I can actually test with (instead of making the user stop working to test), I was able to narrow it down to the loading of the menu of the window. Turns out some of the menu items were using icons that were not specified in the PBR. Removing the reference to those icons altogether made it work as expected for all users. As of now I am working with our network admins  to figure out why for some Citrix logins the search for those icons worked quickly and for some logins it is painfully slow since it would be searching through their path to try to find the icons (which it wouldn't ever be able to find).

For now, however, the window is functioning for everyone since having no icon on the menu item isn't a show stopper!

Thanks for getting me headed in the right direction...