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?

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,

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.

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

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?