Pega Static Assembler Utility - Implementation plan
We are planning to implement static assembly process across all the application. There are applications which are in Pega 6.x and in 7.x as well.
We ran the utility in the development environment, which took approximately 2 hrs to complete the process. Below is the snapshot of the log entries which summarizing the completion status.
jvm1 STATIC ASSEMBLY SUMMARY
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - ===========================================================================
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Processed : 116156
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Assembled : 114352
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Not Assembled : 400
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Not Eligible : 1404
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - Total Duration taken (in Sec) : 2421
I have below questions which needs to be clarified in order to better plan the production implementation.
We are planning to implement static assembly process across all the application. There are applications which are in Pega 6.x and in 7.x as well.
We ran the utility in the development environment, which took approximately 2 hrs to complete the process. Below is the snapshot of the log entries which summarizing the completion status.
jvm1 STATIC ASSEMBLY SUMMARY
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - ===========================================================================
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Processed : 116156
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Assembled : 114352
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Not Assembled : 400
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - No of Rules Not Eligible : 1404
2017-03-15 10:52:29,777 [ ftwldscimw118] [ STANDARD] [ ] (ly.metrics.PrimerStatCollector) INFO - Total Duration taken (in Sec) : 2421
I have below questions which needs to be clarified in order to better plan the production implementation.
-
In case of multi node clustered environment, is it required to run for each node or cluster? I see there is a property that we set in the prstaticassembly.properties file to specify the no. of JVMs. What is there relevance of that? If the assembled rules gets stored into DB then running it only once should serve the purpose , please confirm if my understanding is correct.
-
Does static assembly process only update DB or it also update the disk?
-
PRPC 7.1.X the “Static Assembler” is available for the user to kick off himself at (Pega button) > System > Tools > Static Assembler. Does that mean after new code deployment running this from one of the node is what required to pre-assemble all the rules?
-
How to verify that all the required assemble is done and the end user is benefited from this.
-
Is there a way to not to include based on application each time when we do static assembly ?
-
In the log snapshot there are entries as below, what is the reason of this and do we care about this?
-
No of Rules Not Assembled : 400
-
No of Rules Not Eligible : 1404
-
Thanks
Sarada
Accepted Solution
Pegasystems Inc.
US
Running from designer studio will have the same behavior as running from the command line.
Pegasystems Inc.
US
-
In case of multi node clustered environment, is it required to run for each node or cluster? I see there is a property that we set in the prstaticassembly.properties file to specify the no. of JVMs. What is there relevance of that? If the assembled rules gets stored into DB then running it only once should serve the purpose , please confirm if my understanding is correct.
-
>>> that is correct! since results are stored in the db, dont have to execute for each jvm.
-
-
Does static assembly process only update DB or it also update the disk?
-
>>> its only the db.
-
-
In case of multi node clustered environment, is it required to run for each node or cluster? I see there is a property that we set in the prstaticassembly.properties file to specify the no. of JVMs. What is there relevance of that? If the assembled rules gets stored into DB then running it only once should serve the purpose , please confirm if my understanding is correct.
-
>>> that is correct! since results are stored in the db, dont have to execute for each jvm.
-
-
Does static assembly process only update DB or it also update the disk?
-
>>> its only the db.
-
-
PRPC 7.1.X the “Static Assembler” is available for the user to kick off himself at (Pega button) > System > Tools > Static Assembler. Does that mean after new code deployment running this from one of the node is what required to pre-assemble all the rules?
-
>>> it depends on no of rules being introduced in the release. for incremental releases, most likely you dont need them. probably you may want to validate it in one of the envs like QA/Test to determine the benefit.
-
-
How to verify that all the required assemble is done and the end user is benefited from this.
-
>>> after the static assembler execution, if users start using the application, there should not be any additional updates to 'pr_assembledclasses' table, since rules should be assembled already.
-
-
Is there a way to not to include based on application each time when we do static assembly ?
-
>>> this could be a product enhancement, if you could show the evidence & benefits.
-
-
In the log snapshot there are entries as below, what is the reason of this and do we care about this?
-
No of Rules Not Assembled : 400
-
No of Rules Not Eligible : 1404
-
>>> looks like an information only. while verifying assembly results, if you notice additional updates to 'pr_assembledclasses' table, then this numbers needs to be revisited.
-
-
Pegasystems Inc.
US
3.2) set 'jvm.instances' property by specifying the number JVMs to be launched for assembly. Make sure the number starts with 1 and separated with commas
eg: jvm.instances=1,2,3
This property is about dividing up the work. You can spin off more than 1 jvm to actually do the assembly. It isn't that if you specify 3 that all 3 will be doing the same thing but that each will do a 1/3 of the work.
Cognizant Technology Solutions
US
Thanks Gopi and Celeste for providing these useful info. This will help planning this utility to execute in production environment.
I have now below additional questions,
1. I was thinking to run this utility each time there is a release deployment with a good amount of new/modified features going to production and hence will have a better User Experience (performance wise) on the next day. That is the reason of asking why the "based on" application is required to assembled every time. Please suggest when and how often we should run this utility to get the maximum benefit.
2. In the log snapshot there are entries as below, what is the reason of this and do we care about this?
-
No of Rules Not Assembled : 400
-
No of Rules Not Eligible : 1404
Is it really informational ? In the log there are exceptions ( exactly 400) for each rules that are not assembled. I am attaching the log for your reference. Please confirm if we shouldn't worry about these.
Cognizant Technology Solutions
US
few more question:
1. In PRPC 7.1.X the “Static Assembler” is available for the user to kick off himself at (Pega button) > System > Tools > Static Assembler. Is it exactly the same as running the above utility from application server as standalone/ utility mode.
2. If both process are same , why it was suggested to run the utility while the application is stopped but in case of (Pega button) > System > Tools > Static Assembler it is only possible to run when the application is running.
Pegasystems Inc.
US
Yes, running after a major release is a good idea for improving the user experience the next day. Those few rules that were not assembled/not eligible are fine.
You can run static assembler from designer studio but it will impact the performance of the system. Plus you would need to make sure that you have a large enough heap available. I would run it from the command line.
Cognizant Technology Solutions
US
thanks Celeste for the reply.
Gopi confirmed before that the command line process only updates the DB tables.
Does running static assembler from designer studio create any cache on the disk or it only updates the DB tables?
Regards
Pattnaik
Cognizant Technology Solutions
US
I am still looking to know, if running static assembler from designer studio create any cache on the disk or it only updates the DB tables?
Regards
Pattnaik
Accepted Solution
Pegasystems Inc.
US
Running from designer studio will have the same behavior as running from the command line.