Ah, I am following you now. Instead of having multiple sets of redundant Active Links (say to refresh a set of tables) for different actions, put one set in a guide and then you just need individual ALs to call the guide instead of duplicating the action ALs for different conditions. Basically make subroutines.
Jason On Wed, Mar 14, 2012 at 1:48 PM, Joe Martin D'Souza <jdso...@shyle.net>wrote: > ** > Its not a hard hitter but it accounts for smaller cache sizes by reusing > code instead of recreating it everytime its required.. Useful when every > run counts.. Wont make a big difference if your application footprint is > small. > > Joe > > *From:* Jason Miller <jason.mil...@gmail.com> > *Sent:* Wednesday, March 14, 2012 4:45 PM > *Newsgroups:* public.remedy.arsystem.general > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Performance Tuning > > ** Hi Joe, > > Can you expand on why using an guides (particularly AL) increases > performance? > > Thanks, > Jason > > On Wed, Mar 14, 2012 at 7:52 AM, Joe Martin D'Souza <jdso...@shyle.net>wrote: > >> ** >> >> You could add a few more to that jar that I can think at the top of my >> head... >> >> #15 Select appropriate Refresh Option for menus depending on their use >> (On Connect, On Open, 15 Minute Intervals). >> #16 Use Active Link or Filter Guides where possible. >> #17 Refresh your table fields only when necessary & use appropriate >> chunks sizes >> #18 Design Flashboard variables carefully. >> #19 Use Computed or Dynamic groups where possible... I’m guessing this >> does impact performance too?? >> >> I’m sure there are other performance related AR System related >> parameters.... Might be a good idea to compile a good list more relevant to >> our current versions.. >> >> Joe >> >> *From:* patrick zandi <remedy...@gmail.com> >> *Sent:* Wednesday, March 14, 2012 10:13 AM >> *Newsgroups:* public.remedy.arsystem.general >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: Performance Tuning >> >> ** I am looking at a jar in front of me.. it says the following:: >> #1 use indexes appropriately >> #2 use efficient queries >> #3 consider using set field action in filters instead of AL >> #4 avoid using filters which perform run process to run a macros (old) >> ##5 stagger escalations times >> #6 use direct sql, $PROCESS$ sparingly >> #7 avoid sending notifications to too many addresses (hah!) >> #8 minimize the number of diary, and long charcter fields >> #9 avoid admin tool / migrator during peak hours. >> #10 keep your application design simple >> #11 implement MPSO (hah!) >> #12 Define carefully the number of fast and list servers. >> #13 allocate enough shared memory for the db. >> #14 provide adequate computer network resources. >> >> Most still apply ! >> >> >> On Wed, Mar 14, 2012 at 10:05 AM, Barber, Sue <sbar...@mitre.org> wrote: >> >>> ** >>> >>> I would be interested in that as well!**** >>> >>> **** >>> >>> Sue**** >>> >>> **** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> arslist@ARSLIST.ORG] *On Behalf Of *Pruitt, Christopher (Bank of >>> America Account) >>> *Sent:* Wednesday, March 14, 2012 9:54 AM >>> *To:* arslist@ARSLIST.ORG >>> *Subject:* Performance Tuning**** >>> >>> **** >>> >>> ** **** >>> >>> Does anyone know where I can find a Performance Tuning guide or white >>> paper for the following AR System Server versions?**** >>> >>> **** >>> >>> 7.1 and 7.6.04.**** >>> >>> **** >>> >>> I have gone through the Optimizing and Troubleshooting Guide for both >>> versions but I thought there was a more detailed Performance Tuning guide >>> out there somewhere. I have gone through BMCs documentation for both >>> versions and have search the BMC Communities and have not found them >>> anywhere. Anyone have a like to these guides, I would really appreciate it >>> if you would provide it.**** >>> >>> **** >>> >>> Thanks.**** >>> >>> *Christopher Pruitt* >>> Business Consulting III **** >>> >>> *HP Enterprises Services >>> **christopher.pru...@hp.com >>> *www.hp.com **** >>> >>> **** >>> >>> **** >>> >>> *Confidentiality Notice:* This message and any files transmitted with >>> it are intended for the sole use of the entity or individual to whom it is >>> addressed, and may contain information that is confidential, privileged, >>> and exempt from disclosure under applicable law. If you are not the >>> intended addressee for this e-mail, you are hereby notified that any >>> copying, distribution, or dissemination of this e-mail is strictly >>> prohibited. If you have received this e-mail in error, please immediately >>> destroy, erase, or discard this message. Please notify the sender >>> immediately by return e-mail if you have received this e-mail by mistake. >>> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
