If you refresh multiple tables via one active link, it now treats them as one roundtrip between client and server, verified with fiddler.
I believe this is 7.6.4 forward, there are good opportunities for some optimization if you see multiple refreshes on unrelated tables (order of refreshes cannot be controlled when this is done) Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: Axton <axton.gr...@gmail.com> Sender: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> Date: Wed, 14 Mar 2012 19:54:23 To: <arslist@ARSLIST.ORG> Reply-To: arslist@ARSLIST.ORG Subject: Re: Performance Tuning As far as the work is concerned, the net cost of the operations is the same, when using an active link guide versus an active link, to perform some set of actions. The difference should be negligible. Now, if you could somehow send one request to the arserver and retrieve the data for all the table fields at once, that would be a different story. It would also be a different story if the javascript used asynchronous calls to refresh the table fields. The active link processing is serial though; this is why the output to the logs is serial and why the request/response pairs are serial. I think it would be a grand change if they could extend the active link processing (and subsequently, the javascript used to emulate the active link processing) to break down the workflow and make a determination on when synchronous/asynchronous calls could be used. I would even take the ability to manually specify which calls are asynchronous and which are synchronous (where the branching in the execution can occur) and define the synchronization points in the workflow. This change would go a long way on the performance of the applications and it would let you have the best of both worlds (visual characteristics and performance). Axton Grams On Wed, Mar 14, 2012 at 6:55 PM, Jason Miller <jason.mil...@gmail.com>wrote: > ** 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"_ >> > > _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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
