Posts tagged "performance"

Acrobat/Reader: poor performance opening a PDF with a smart card

Issue

It takes a long time to open a PDF file when there is a smart card attached to the computer.  This issue can occur regardless of whether the smart card is used in Acrobat/Reader.

Solution

Update to Acrobat 9.4.5, 10.1, or later.

Additional information

When the smart card is attached to the computer, Acrobat detects there is a certificate available. It tries to validate the smart card by checking the certificate chain in the Acrobat and the Windows trust stores. There is a known issue in Acrobat where the algorithm performing this certificate check is inefficient and loops through the chain multiple times. Adobe has improved the performance of the certificate check. However, it has no influence over the other components that lead to the total delay where a smart card is inserted. There are also known delays in smart cards, the reading device and driver, and in the Windows trust store.

reference: (182022367/2710575)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

Acrobat/Reader: slow display performance in Terminal Server or Citrix environments

Issue

When you view PDF files in Adobe Acrobat or Adobe Reader in a Terminal Server/Citrix environment, the display is slow to update over an RDP connection.  This issue is particularly noticeable when scrolling through PDF documents that contain high-resolution images.

Solutions

Solution 1: Update the Page Display preferences in Acrobat or Reader.

Change the following settings in Acrobat or Reader.  You can either disable these options directly in Reader/Acrobat under “Edit > Preferences > Page Display > Rendering”, or using the registry keys for system administrators:

  • deactivate “2D Graphic accelerationHKCU\Software\Adobe\Acrobat Reader\9.0\AVDisplay – bUse2DGPUf=dword:0
  • deactivate “Smooth imagesHKCU\Software\Adobe\Acrobat Reader\9.0\Originals – bAntialiasImages=dword:0
  • deactivate “Smooth line artHKCU\Software\Adobe\Acrobat Reader\9.0\Originals – bAntialiasGraphics=dword:0
  • set “Smooth Text” to None (optional: some customers have reported acceptable performance without setting Smooth Text to None)
    • HKCU\Software\Adobe\Acrobat Reader\9.0\Originals – bAntialiasText=dword:0
    • HKCU\Software\Adobe\Acrobat Reader\9.0\Originals – iAntialiasThreshold=dword:0
    • HKCU\Software\Adobe\Acrobat Reader\9.0\Originals – benableDDR=dword:0

Changing registry values is not officially supported by Adobe and you do so at your own risk.  You should only be changing the registry settings if you have the correct privileges and experience in this area.

System Administrators should change these settings first using the Preferences dialog in Adobe Reader (not using the registry) and re-test the performance through Citrix.  Once you have the right combination of settings that work, then you should record the values of these registry keys to use for your other Reader installations.  This is important as the value of the iAntialiasThreshold key can differ (0, 1, or 12) depending on which of the other options are deactiviated.

Note: These settings will improve the display performance on low-bandwidth connections, however, they can adversely affect the display performance on LAN connections.  You will need to test these thoroughly.

Solution 2: Use an RDP compression tool to compress the data being sent “over-the-wire.”

RDP sends the entire set of image data each time the image is scrolled on the page.  Sending all the data at once can cause congestion on the network connection, especially with limited bandwidth.  Some customers have had success using the following tool to improve the display performance on Terminal Server for low-bandwidth connections: http://www.ericom.com/ericom_blaze.asp

Additional information

There are no general solutions in Acrobat or Reader to improve performance problems in Terminal Server. Performance issues are often based on the bandwidth limitations of the network connection, or the RDP protocol itself.

The RDP protocol does not always handle image data well.  A terminal server on Windows 2003 Server uses RDP version 5.2.  A terminal server on Windows 2008 Server uses RDP version 7.0, which does improve display performance for images.  Therefore, an upgrade to a later operating system can also improve the performance if it uses a more recent RDP version like 7.0.

Here is an article from Citrix referring to the same issue:

http://support.citrix.com/article/CTX122914

and an entry in ourn forums discussing the same:

http://forums.adobe.com/thread/439803

reference: (181990819)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 5.8/10 (4 votes cast)

LiveCycle ES: Performance of AdminUI stalled operations and branches list is slow

Issue

 If you are using the Administration UI for Process Management and particularly the stalled operations/branches views in LiveCycle ES 8.2.1, you may notice it takes a long time to return the list of stalled items, particularly if there are many pages to be returned.  In some environments a delay of up to 1 minute can be observed which would be unacceptable for a production environment where the IT team need to be able to react quickly to any stalled instances in production.

This issue has been reported mainly with Oracle databases.

Solution

 The following SQL statements will add indexes to the appropriate tables in the LiveCycle database which will greatly improve the performance of these AdminUI views:

CREATE INDEX status_idx ON tb_action_instance(status);
CREATE INDEX sub_status_idx ON  tb_branch_instance(sub_status);

These indexes need to be created manually in ES (8.x) and ES2 (9.x) as they cannot be applied through ServicePacks.  The issue is fixed in ADEP (ES3).

reference: (181470980/2570677)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycle ES: Change Workspace AMF Polling interval

Issue

If you are using LiveCycle Workspace ES you will notice that it is polling the LC server every few seconds for updates. You can see the polling frequency by using a web logging tool like Fiddler2 and analyzing the logs for the entries related to “messagebroker/amfpolling”.

The polling is used to update the user and group queues with task information. Each Workspace client polls the server with this frequency, which may start to affect the performance. In this case, the polling interval can be changed, especially if you are using task assignment e-mails, which makes the automatic updates in Workspace less critical.

Solution

The polling interval in Workspace uses the default value defined by the AMFChannel. Unfortunately, it is not possible to build a patch to expose this property or to set it to a fixed value. Doing so would mean creating a customized version of Workspace for one customer and maintaining this version separately from the standard Workspace for all other customers.

A better solution is to allow you to control this property in your own Workspace version. This can be achieved through a small modification of the Workspace source, which would be applied when you are customizing your Workspace client.

In the createChannelSet() method defined in lc.core.Manager, the AMFChannel is created as follows:

var channel:AMFChannel = new channelClass(channelId, channelUrl);

You can add the following line just below that to set the pollingInterval to whatever value works best:

Channel.pollingInterval = xxxx;

Note: The xxxx value is in milliseconds (ms).

Additional Information

In Workspace ES3, the polling interval can be configured via the Workspace Global Administration.   Customizing Workspace is no longer required.

Just export the global settings file under Services > Workspace > Global Administration > Export Global Settings, change the value of

<client_pollingInterval>3</client_pollingInterval>

…, save the file, and re-import it.  Restart the application server.

reference: (181438652/2555685)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 8.0/10 (1 vote cast)