1. Robert Shaw
  2. PowerBuilder
  3. Wednesday, 25 November 2020 16:04 PM UTC

Hi Folks,

I'm a SysAdmin investigating a problem for an application we develop in-house using PowerBuilder 2019.  We are running it currently on Windows Server 2012 R2 and are seeing some odd behaviour.  We are seeing the same behaviour also in Windows Server 2016.

Let's say we have UserA and UserB.  UserA logs onto the Windows Server 2012 R2 server which hosts this particular application.  UserA starts the app, navigates to a set of search criteria which then goes on to output a load of PDF's to send as an email.  This process runs within a timely manner of 1 min.  We watch the CPU spike on the exe that is currently running, to around 20% and then drop once the process is complete.

UserB logs on and runs through exactly the same process.  Exactly the same search criteria.  However this time, the process can take between 10-15 minutes complete.  When monitoring the same process and it's CPU usage we only see the CPU peak at about 5-6% during the time it takes to run.  If we click on the app window while it is running, we get an AppCrash report showing the DLL that has faulted as the one responsible for the code to run this particular part of the app.

Same server, same level of access to the server, the only difference could be the User Profile.  We have tried using a completely fresh User Profile and that exhibits the same problem as UserB.

Has anyone come across differences in performance depending on Users and their profiles?  Any idea where we should even start to look?

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 25 November 2020 16:15 PM UTC
  2. PowerBuilder
  3. # 1

Have you been able to pinpoint what part is slow?  Retrieving data from database?  Printing the PDF?  Generating the email?

How are you generating the PDFs?  Are you using the NativePDF or some third-party PDF solution?

I assume historically this app has not had such performance issue?  If so, then what changed?  

 

Comment
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 25 November 2020 16:44 PM UTC
  2. PowerBuilder
  3. # 2

Hi Robert;

     FWIW: Sounds to me like it might be a work file(s) that are in conflict until a lock is released. This could happen when these file(s) are found in a common work area versus in each MS-Window user's work folder (ie:  " C:\Users\<Window User>\AppData\Roaming\<AppName> " )

Food for thought

Regards ... Chris

Comment
There are no comments made yet.
Robert Shaw Accepted Answer Pending Moderation
  1. Wednesday, 25 November 2020 17:08 PM UTC
  2. PowerBuilder
  3. # 3

Hi Both, Thanks for taking the time to respond.

Unfortunately, I'm not the app developer so it's difficult for me to understand exactly what's going on.  I'll try to give you as much info as I do know.

I believe the app is pulling data from the database and generating a PDF.  This is signified by the brief appearance of an hourglass.  It will do this for as many times as PDF will be generated, in the tests we have been doing, 15.

I have been told it is using NativePDF they don't use any 3rd-party to generate the PDF's.

All of the EXE's are stored centrally under the Apps folder on the C Drive.  There is a PBCommon folder that houses all of the common DLL's.  I'm being told that none of the EXE's contain code any more, all of the code is held in the DLL's.

There have been changes, we had a big change release a couple of weeks ago, but again, I'm not a developer so not sure of the exact changes and by the sounds of our Development team they're also not sure what change could have affected this.

The developers tend to code on Windows 10 Workstations which all behave in the same way as UserA, CPU Spike of 20% and done within a minute or so.  On the Server OS it works much slower and a lower CPU spike.  That was until we tested with UserA, who exhibited the same experience as on a Windows Desktop.  Initially we thought maybe there was a fundamental difference between how the App is handled on a Server OS to a Desktop OS, but that doesn't appear to be the case.

Sorry I can't give any solid technical details, I just wondered if someone had come across a similar issue before and where we should even start to look.  It seems to be something related to the User Profile, I just can't work out how.

Comment
There are no comments made yet.
Mark Lee @Appeon Accepted Answer Pending Moderation
  1. Thursday, 26 November 2020 09:17 AM UTC
  2. PowerBuilder
  3. # 4

Hi Robert,

 

I suggest that you check the difference between the User Profile of UserA and UserB.

Since you are not certain if it's caused by a Printing PDF issue or a Generating email issue or other issues, I can only assume that this is a NativePDF related issue. In this way, you need to check if the logged-in user has the permission to create or delete temp files in %temp%.

 I also suggest you can copy the log.ini file (see the attachment) to the Temp folder (default path: C:\Users\appeon\AppData\Local\Temp\Appeon\NativePDF\Log) to enable the NativePDF log file.

And then you will find that the log file is generated under this folder after you use the NativePDF function to generate the PDF file.

You can compare the log files of UserA and UserB and see the difference between them and also see if they took about the same time to create the PDF.

I would still suggest that you contact your developers to locate the specific code that has the performance issue by adding a method like messagebox in the program.

If it can be confirmed that the issue is with the PB code, please report this problem to our ticket system:https://www.appeon.com/standardsupport/newbug and meanwhile provide these log files and the reproducible test case in the ticket for us for analysis.

 

Regards,

Attachments (1)
Comment
  1. Robert Shaw
  2. Thursday, 26 November 2020 11:34 AM UTC
Thanks Mark,

After yet more testing, we have discovered something even more unique. I have been using Remote Desktop Connection (mstsc.exe) from my Windows Desktop to the remote server and running the application. Using that produces the problems that I reported initially. Each PDF takes around 15 Seconds to complete giving me a total completing time for 15 PDF's of around 4 minutes.

I downloaded Microsoft Remote Desktop from the Microsoft Store this morning and connected to the Remote Server using that. This method runs much quicker, dropping the time between PDF's to just 1-2 seconds and completing in less than a minute.

If I take over that session using Remote Desktop Connection (mstsc.exe) it continues to be fast. If I log off and log back in using Remote Desktop Connection it goes back to being slow.

I have also logged on with a Console Session to the box from VMWare and run through the same process and the app has performed well.

So now it is starting to look like a method of access affects the performance of the App. This is all very strange.
  1. Helpful
  1. Mark Lee @Appeon
  2. Friday, 27 November 2020 03:43 AM UTC
Hi Robert,



Yes, this is a really peculiar issue.

And thanks for sharing the resolution with us.



Regards,
  1. Helpful
There are no comments made yet.
Ronnie Po Accepted Answer Pending Moderation
  1. Friday, 27 November 2020 17:35 PM UTC
  2. PowerBuilder
  3. # 5

Hi Robert,

Just some random thoughts:

Is UserB's home directory mapped to a different (slower) volume than UserA's?

Is there any sort of virus scanning going on in the background for UserB that might be slowing down the temp file creation?

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.