PRPushservlet is pain for us since Pega 831 upgrade. Everytime we keep DSS at ON for pushservlet we are having multiple thread taking 2 min timeframe to process. Pega alerts and logs are not showing any hint for this but performance test and production we can see impact.
WE want to keep this feature on due to robotics dependencies- logging and push notifications
These requests are long-polling requests for notification channels. The user’s browser opens a request to the Pega server, which is held open to allow the server to send a notification. After an interval, the connection is closed and the client opens another one. Therefore you will see an idle connection held open to PRPushServlet and this is working as intended. You can ignore these requests in your load testing or when viewing interactions in APM software.
This method is a fallback mechanism when websockets are not enabled. Pega will first try to open a websocket, if it fails then it uses the long polling mechanism instead. It would be more efficient to enable websockets in your infrastructure which would then eliminate these HTTPS requests entirely.
Hi Bushan, what is the DSS you are using to enable PRPushServlet?
default it’s enabled - prconfig/server-push/enabled/default
if you want to disable then put to false. but seeing multiple reply from expert and support. we should avoid to disable it.
we will get multiple question from performance team and support when they see long running in Dynatrace or Appdynamic. we need to answer them all artifacts.
|
No one has been able to substantiate the performance impacts on users since I keep getting the same reply that this is only seen in splunk and dynatrace. The PRPushServlet is working per design and is not a concern regarding performance issues. The way the PRPushServlet works is below. The PRPushServlet attempts to make a websocket connection and if this fails it will revert to longpoll. It appears in your case it has reverted to longpoll. The longpoll will make a request and sits idle waiting for a message. If no message is received them it will time out and initiate the long poll request again. Pega is using the Servlet 3.0 async APIs. The Servlet API provides 2 APIs: suspend and resume. When the long poll is waiting for a response /message the thread is put into a suspend state. When it is in suspend it clears all resources and allows all other requests to use the thread. If a message arrives for longpoll then it will wake up with a resume and process the message. A thread would then be associated with the request and the message would be sent back to the browser. This is not blocking longpolling, therefore there is no performance impact. The dynatrace indicates you are running on jboss which in certain versions does not enable websockets out of the box. I would reccomend you validate your version and enable websockets. Websockets is a bi-directional communication that runs on top of the HTTP protocol. Once this is enabled you will not see these polling requests, since websockets establishes a single connection at which point all messages are sent through the initial connection. Steps to enable websockets in jboss: JBOSS EAP 6.4.0 GA and 6.3.0 GA Note: JBoss 6.1.0 GA does not support websockets. To enable the support for websockets we need two changes 1. Modify jboss-web.xml in the war file to enable websockets In prweb.war/WEB_INF/jboss-web.xml, add below tag true just before 2. Change JBoss to use the NIO connector Open $JBOSS_HOME/standalone/configuration/standalone-full.xml and change to This will need our PRPC redeployment as we are changing deployment descriptor (jboss-web.xml) If you have any questions please let me know. Thank You. |
