Time required to open attachment

Hi all,

Some of our users has been saying it's taking too long to open up an attachment. We think this has to do with the attachment size and their computer speed. However, is there anything we can do on PRPC side to help improve it? Thanks.

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.


Keep up to date on this post and subscribe to comments

January 9, 2012 - 7:19am

Hi All,

Does any one have any answer on how to resolve the given issue .We are also experincing the same problem.In our application the call center guys are using pega attchment functionality extemsively the time consumed for notes to open is resulting in extended call with customer.

Any help would be appriciated!

March 10, 2010 - 8:51am

Are you using the OOTB code for attachments?

March 16, 2010 - 11:25am

Yes, we do use the OOTB code for attachments. Thanks!

March 16, 2010 - 12:04pm

Sara wrote: Some of our users has been saying it's taking too long to open up an attachment. We think this has to do with the attachment size and their computer speed. However, is there anything we can do on PRPC side to help improve it? Thanks.

Which version are you on?
I thought I answered this earlier; maybe I never submitted it.

My gut sense is that there's a bottleneck in the Base64 conversion.
Perhaps someone has run performance tests across attachment sizes?

The alternative is to use an enterprise content management to store attachments.


March 16, 2010 - 12:36pm

Hi Jon,

We are currently on v5.1sp2.
Is there any information on PEGA site regarding setting up the enterprise content management to store attachments? Ex. the migration of the attachments in PRPC DB to some other location. Thanks.

March 16, 2010 - 3:06pm


We are considering the possibilities of the following to help improve the performance of attachment opening. Has anyone done the same and can suggest which is the most effective?

1) Upgrading to newer version (not sure if it'll make a difference)
2) Performing DB tuning
3) Archiving work objects

Thank you.

March 17, 2010 - 12:35am

Simple couple of solution than going advance changes.
1. Restrict big size attachment. Not allow to attach more than 25 MB attachment, we came across same issue when open more than 25 MB attachment.

2. do not allow BMP image etc.. , convert to jpg or some other less heavy type and attach.

March 17, 2010 - 12:37pm


Thanks for the suggestions. Did you also attempt any other way to improve this (besides restricting users on their attachments)? Do you mind also letting us know what version you are on? We are currently on v5.1sp2. Just wondering if the verions makes any difference. Thanks!

March 17, 2010 - 2:11pm

RAJAKULP wrote: Simple couple of solution than going advance changes. 1. Restrict big size attachment...

Sorry, simply telling the customer to "use smaller inputs" is not an acceptable solution. That said, Sara, can you confirm the size of the attachments that are taking too long? What is the size, and what is the latency?

I have to correct my previous statement about the Base64 conversion being a bottleneck. My improved educated guess is that the pre-v5.5 method of writing the file to disk before sending it to the outputstream (call it "dump and pump") was not very efficient (and may have entailed security risks as well). In v5.5, Pega has streamlined this to the to the function tools.sendFile(), as used by DisplayAttachFile:

tools.sendFile(strWorkObjectRef, "pyAttachStream", true, "pxAttachName", null, false, null, true);

Unfortunately, this functionality is near-impossible to hack without an upgrade of the engine to v5.5. Pega does not provide access to the HttpServletResponse interface, so you cannot simply stream bytes to the client as you would like.

Still, I defer to somebody with both v5.5 and a previous version (Pega, or any of you) to provide the metrics on both.


March 17, 2010 - 3:19pm

Hi Jon,

We don't really know the size but I'm assuming couple MB and there are some cases with many attachments. Users were saying it takes over minutes to open them. It's good to know that it has improved in v5.5 [:)] However, if our business does not have the appetite to upgrade to v5.5 yet, would there be anything else that we can do to improve this? Thanks very much!

March 17, 2010 - 4:01pm

Have you checked your Alert files? What about PAL? Does this happen with all users or only a few? Is this a recent problem? Is it the database, the call to the database, the creation of the file, the transmission of the file or the rendering of the file to the browser? You should identify where the bottleneck is occurring first before attempting any solutions as there are too many variables in play.

March 18, 2010 - 10:10am


We have been receiving the following alerts from the log:
2010-03-17 14:03:56,572 GMT*2*11d44c5b85b5c29a03e723d212399aa0*1777*13*WebContainer : 5*pegarules.services.HttpAPI*H0A0AC0E52A3DF15746C7AF301DC93FB4*TSEC5*w3.xxx.xxx.xx.com|*PEGA0001*68260*1000*HTTP interaction has exceeded the elapsed time alert threshold of 1000 ms: 68261 ms. Request: https://w3.xxx.xxx.xx.com/prweb/PRServletAuditLDAP/RBPJFS_u3rTHwlMGLb64H8NHIiEBKuYagIWQ51ULuvo3-1p-uyPUV_3YfsSmvXeoIchO-Zhp9AY%5B\*/!STANDARD?pyActivity=XX-Audit-Investigations.HistoryAndAttachments
2010-03-17 14:04:02,067 GMT*2*11d44c5b85b5c29a03e723d212399aa0*1778*14*WebContainer : 5*engine.database.DatabasePreparedStatement*H0A0AC0E52A3DF15746C7AF301DC93FB4*TSEC5*w3.xxx.xxx.xx.com|*PEGA0007*4593*500*Database operation took more than the threshold of 500 ms: 4593.75 ms SQL: SELECT pzPVStream FROM pc_link_attachment WHERE pxLinkedRefFrom = ? AND ( pxObjClass = ? )

This has been happening to all users, and it's not a recent issue. However, it seems to have got slower and slower performance as days goes by. There is about over 50000 workobjects in the application, and most of them do have attachments.
The users are finding it time consuming to open the the attachment stored in a work object.

I tried to view the PAL in a test environment, but it doesn't take that long to open up an attachment in test. Perhaps because the number of work objects and attachments are way less than that of PROD?

Any suggestions on improvment would be appreciated. Thanks!

March 18, 2010 - 10:58am

Remember that the activity HistoryAndAttachments
and the query SELECT pzPVStream FROM pc_link_attachment WHERE pxLinkedRefFrom

do not represent the opening of an attachment, but rather the listing of them.

Do you have indexes on the pc_link_attachment table? I don't have the v5.1 schema in front of me, and I don't know if an index on pxLinkedRefFrom was specified in it.


March 18, 2010 - 12:59pm

Hi Jon,

Thanks! That's a very good point. The pxLinkedRefFrom column is not indexed. Perhaps indexing it would help with the performance. [:)]

April 10, 2010 - 8:49pm

In OOTB Attachments HTML rule, please try to find a code for scanning purpose. Due to some reason, this code is calling every time you need to disable it in PRPC v5.1 version.

Let me know the result.

Also, you need to identify the list of columns to be exposed in DB because it is currently querying from BLOB too.

To check performance, use Explain PLAN command to understand the Cost of SQL query as well.

April 12, 2010 - 9:43am


I've tried indexing the pxLinkedRefFrom column, and according to the Oracle Explain Plan in our test environment, it did speed up the query.

I'm not sure of what HTML rule do we need to disable? And does this mean it is disabled on later versions of PEGA?


May 24, 2012 - 5:06pm


One of our business requirements is that our PRPC application should support 2 attachements with every work object, max size 500 kb for word doc and 50 kb for pdf. Do you think prpc v 6.2 will support it?