Doug Mueller gave an excellent response almost two years ago regarding this topic (subject: Logic in active links vs. filters). What he outlines is right in-line with your thoughts.
http://old.nabble.com/forum/ViewPost.jtp?post=28271031&framed=y Jason On Wed, Mar 14, 2012 at 2:37 PM, Jose Huerta <jose.hue...@sm2baleares.es>wrote: > ** About the recommendation of using AL instead of Filters to increase > performance, I know that BMC recommends it, but I think that is a big > mistake. In fact it can increase performance, but at the price of degrading > the business logic layer. I can explain it with an example: Tell a Java > developer to move the business logic code from the server to javascript to > free server resources. Just this morning I published a post that contains > this point of view, what a coincidence! > http://theremedyforit.com/2012/03/bmc-and-dirty-programming/ > > Jose M. Huerta > Project Manager** > > Movil: 661 665 088 > > Telf.: 971 75 03 24**** > > Fax: 971 75 07 94**** > > <http://www.sm2baleares.es/>**** > > SM2 Baleares S.A. > C/Rita Levi **** > > Edificio SM2 Parc Bit**** > > 07121 Palma de Mallorca**** > > <http://es-es.facebook.com/pages/SM2-Baleares/158608627954> > <http://twitter.com/#!/SM2Baleares> > <http://www.linkedin.com/company/sm2-baleares> > > La información contenida en este mensaje de correo electrónico es > confidencial. La misma, es enviada con la intención de que únicamente sea > leída por la persona(s) a la(s) que va dirigida. El acceso a este mensaje > por otras personas no está autorizado, por lo que en tal caso, le rogamos > que nos lo comunique por la misma vía, se abstenga de realizar copias del > mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de > inmediato.**** > > P Por favor, no imprima este mensaje ni sus documentos adjuntos si no es > necesario. > > > > On Wed, Mar 14, 2012 at 21:48, 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"
