Hopefully these types of things are being considered for a future version that may or may not be a major overhaul to the core ARS code. On Mar 14, 2012 5:54 PM, "Axton" <axton.gr...@gmail.com> wrote:
> ** 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"_ >> > > _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"
