Question
Last activity: 21 Mar 2016 21:33 EDT
Report display performance @BrowserIsFireFox took several time
Now I am facing low performance of report display.
By tracing, DB performance seems not bad, it took Display rendering.
And found some delay had come from some When rule. On of example is @BrowserIsFireFox (tool).
The report has 11 properties for 1345 rows, all optimized, 3 items used by sort parameter. I have tested it IE11, FireFox v.43.04
The trace was collected by FireFox v43.04 and we can see it "false" as the result of When rule.
I would like to know how we can stop or make it faster, the when rule (@BrowserIsFireFox) for rendering performance.
@BrowserIsFireFox function checks simply browser type around 100-300 ms but the Report activity seems to call this function times of number of properties.
List h = ((com.pega.pegarules.priv.PegaAPI)tools).getHTTPHeaders("User-Agent");
if(h == null){
return false;
}
else{
String s = (String)h.get(0);
if(s.indexOf("Firefox/") > 0)
return true;
else
return false;
}
Indeed this is not a longest part of latency for Report's display rendering, should clean up each by each.
Yas
Pegasystems Inc.
US
Yas,
Can you please provide some general information?
- Which Process Commander Version is this?
- Which database version is this? Please provide the version number, and any fixpack version information. Example: Oracle Proprietary information hidden / DB2 UDB 10.0.27 / Microsoft SQL Server 2010
- Which Web Application is this? Please provide the version number, and any fixpack version information. Example: WebSphere Proprietary information hidden / Tomcat 7.0.43
Thank You
Updated: 11 Feb 2016 18:20 EST
Thank you for reply for this
I know this would not take big parts of performance (see attached), indeed. But I wonder still asking browser version,
And we know low performance comes a lot of stacks of these small actions.
The site is cloud system. http://ps-585.pegacloud.com/prweb
Here is the brief information.
Tomcat version /6.0.32(system information is also attached)
PRPC 718_675
Sun Java 1.6.0_14-b08 with heap 2033MB
Oracle Proprietary information hidden.0
On Linux EL5 on a Xen virtual server. I could not get the number of cpu cores.
Either I could not get ojdbc6.jar version in detail.
Regards,
Yas.
Pegasystems Inc.
US
Yasuhiro,
Good Day. Again, I hope all is well with you.
Thank you for providing your environment information. I have reviewed the information, and your platform/environment is supported per the Platform Support Guide.
***
Next, per the PRPC Implementation Guide, you are running with a JVM Heap Size that is too small. The Implementation Guide states that you must run with at least 4.0GB of Heap Space in a DEV environment, and run with at least 4GB to 8GB of heap space in a PROD environment.
An undersized heap might be contributing to your performance problem, so please implement the following change in your JVM switches:
-Xmx=4096m
-Xms=4096m
***
Next, please implement the following switches to ENABLE GC logging:
-verbose:gc
-Xloggc:"<CATALINA_HOME>\logs\tomcat718_gc.txt"
-XX:HeapDumpPath="<CATALINA_HOME>\logs\tomcat718_heapdump.hprof"
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintCompilation
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags
Implementation of these switches is critical to continuing an investigation of this issue. Please ensure that these switches are implemented in your environment. After implementing these switches, a shutdown/restart of the Tomcat instance is required.
***
Yasuhiro,
Good Day. Again, I hope all is well with you.
Thank you for providing your environment information. I have reviewed the information, and your platform/environment is supported per the Platform Support Guide.
***
Next, per the PRPC Implementation Guide, you are running with a JVM Heap Size that is too small. The Implementation Guide states that you must run with at least 4.0GB of Heap Space in a DEV environment, and run with at least 4GB to 8GB of heap space in a PROD environment.
An undersized heap might be contributing to your performance problem, so please implement the following change in your JVM switches:
-Xmx=4096m
-Xms=4096m
***
Next, please implement the following switches to ENABLE GC logging:
-verbose:gc
-Xloggc:"<CATALINA_HOME>\logs\tomcat718_gc.txt"
-XX:HeapDumpPath="<CATALINA_HOME>\logs\tomcat718_heapdump.hprof"
-XX:+HeapDumpOnOutOfMemoryError
-XX:+PrintGCDetails
-XX:+PrintCompilation
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags
Implementation of these switches is critical to continuing an investigation of this issue. Please ensure that these switches are implemented in your environment. After implementing these switches, a shutdown/restart of the Tomcat instance is required.
***
Next, after making these changes, stop/restart Tomcat and allow the environment to run for at least 24 hours: permit users to login and use the environment. At some point during that time period, re-perform your test as detailed above: trace the slow performing functionality and re-verify your observations.
After the environment has been exercised in this way, please obtain the following logs from the environment:
- Pega logfile
- Pega ALERT logfile
- Tomcat GC logfile (as above: -Xloggc:"<CATALINA_HOME>\logs\tomcat718_gc.txt")
- Trigger a JVM Java Thread Dump. Obtain the log that contains the thread dump. I need one thread dump to view the configuration of the JVM itself - the thread dump will contain a great deal of information about your JVM including its configuration.
Please ZIP all four of these logs together as one ZIP file. Please send this ZIP file to me using the Pega LFTA:
***
NEXT STEPS: When I receive the logfile bundle, I will examine the logs and see if I can find performance problems that could be causing this issue.
THANK YOU
Updated: 12 Feb 2016 17:10 EST
This is not GC issue at all.
I have never seen Garbage collection has wrong. I have already much tune for this environment.
Implict loop function takes long time and no other GC issue comming from there.
Indeed for a few seconds, memory was used and MarkSweep may happen, but this is not performance defect at then.
After GC transtion session finished, the slowness happens.
I wonder why the behavior is correct to believe now? I do not think focusing about performance, but odd behavior is topic on here, please listen to me.
Yas.
This logs were from my environment.
I am using JBOSS EAP 6.1 for 718, JDK 1.7.0_75, Oracle 11.0.2 on CentOS 6.6.
JAVA_OPTS="-Xms4096m -Xmx4096m -XX:NewSize=1024m -XX:MaxNewSize=1024m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseParNewGC -XX:MaxPermSize=1024m -Djava.net.preferIPv4Stack=true -Xloggc:gclog.log -XX:+PrintGCDetails -verbose:gc -XX:+PrintTenuringDistribution "
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
So environment is slightly different but trace data is quite similar.
I have informed the customer CMSInitiatingOccupancyFraction=60 for earlier sweeping to prevent server side hung, already.
After then I would ask to reduce odd behaviors which exhausting running time, each by each.
Sorry for missing these values
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
The gclog is hard to read for matching up but I have only tested loading.
For testing purpose, I had uploaded 50,000 rows and reported by a Report Definition.
I was gazing the gc log by tail -f, Even after stopped gc log scrolling out, Prpc is still in processing for couple of minutes till returning contents to browser.
Indeed browser took a couple of minutes for rendering after then. I assume it was also Pega's java script issue, may-be.
Yas.
Pegasystems Inc.
US
Yasuhiro, please provide me the above requested logs at your convenience and I will take a look at them.
Regards,
Tom
Pegasystems Inc.
US
Yasuhiro, I am trying to look into overall performance of the environment as this may be the cause of the delay in delivering the report data to the browser. If I can not obtain the requested logs from you, then my hands are tied. Can you please provide the logs that I have requested?
THANK YOU
Tom
I have tied to discuss about performance. Just I have posted the issue only focus on inproper repeating verification (seems buggy).
The performance was on an SR , it was a different article. --> Re: SR-A17357 Sev-3 Report view is too slow to display the results prpc 7.1.8.
You can find the logs/ trace on there.
Rgs, Yas.
I cannot get any update of dedicate issue for multiple ignoreable checking browser isFireFox.
It seems tiny for each but this must loose the performance.
Does anyone have any good idea for refraining from the needless action?