The things that slow down applications the most are the work the database has to do and the chatter on the network. Both of these things can be address 90% through application design.
What do I mean by application design? In it's simplest form, I mean "the way you store and reference data." There are things that a person can do to make the presentation nice, but you pay a price for those conveniences. In relation to the database, applications that push lots of data around are going to be inherently slower than applications that do not push lots of data around. The easiest way to address this is to store information only once, and read/reference it from that single location. In relation to the network, applications that talk back and forth a lot are going to be inherently slower than applications that perform all their work in a single request/response pair (the ideal scenario). Active links that set fields, table field refreshes, reading menu values, images embedded in your forms, etc. all require a trip to the server and back. Each active link or form objects that performs one of these operations requires a round trip. The more round trips you have the slower things will be. There are limitations to what Remedy can and can not do natively to address these 2 items. Workflow, join forms, etc. can only take you so far, and to remove the hurdles that Remedy can not address natively requires that you work outside Remedy. Some things that commonly come up in this category include: - database tuning (how you store data, how you configure the database, the disk configuration or storage subsystem characteristics) - data access [one trip to do it all] (join forms only give a limited set of capabilities, to extend beyond that you need to look into other things: plugins, database views, etc.) At the end of the day, the decision that has to be made is the trade-off between visual characteristics (capabilities) and performance. Everyone will fall in a different location with respect to these two competing interests. One has to keep in mind that the balance chosen, once implemented, can not be easily changed. This is why it is critically important to define the goals before the design. Those are the things that can have the most drastic impact to the performance of your system, though it is not something that can be addressed with applications that already exist. Axton Grams On Wed, Mar 14, 2012 at 3: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"
